DEC 0 2 2005 



PTO/SB/21 (02-04) 
Approved for use through 07/31/2006. OMB 0651-0031 
U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE 



/rf/vfy 



t Under the Palferwork Reduction Act of 1995. no Dersons 


ara rpn 1 1 i roH irk rocrvtnH tn a frtllor'tin 


n frf information unlace it riicnlavc a waliH OMR frmlrrJ numhar 




Application Number 


09/881,919 


^ TRANSMITTAL 
FORM 

(to be used for all correspondence after initial filing) 


Filing Date 


06/14/2001 


First Named Inventor 


William K. Bodin 


Art Unit 


2154 


Examiner Name 


Patel, Haresh N. 


\^ Total Number of Pages in This Submission 54 


Attorney Docket Number 


AUS920010619US1 



ENCLOSURES (Check all that apply) 



□ 
□ 

□ 
□ 
□ 

□ 
□ 



Fee Transmittal Form 

Fee Attached 
Amendment/Reply 

□ After Final 

□ Affldavits/declaration(s) 
Extension of Time Request 
Express Abandonment Request 
Information Disclosure Statement 

Certified Copy of Priority 
DocumenUs) 

Response to Missing Parts/ 
Incomplete Application 

□ Response to Missing Parts 
under 37CFR1.52 or 1.53 



□ 
□ 
□ 
□ 
□ 
□ 
□ 
□ 



Drawing(s) 

Licensing-related Papers 
Petition 

Petition to Convert to a 
Provisional Application 
Power of Attorney, Revocation 
Change of Correspondence Address 

Terminal Disclaimer 
Request for Refund 
CD, Number of CD(s) 



□ 

□ 

□ 
□ 
0 



After Allowance communication 
to Technology Center (TC) 

Appeal Communication to Board 
of Appeals and Interferences 
Appeal Communication to TC 
(Appeal Notice, Brief, Reply Brief) 

Proprietary Information 



Status Letter 

Other Enclosure(s) (please 
Identify below): 

Appeal Brief; 3 References; and Postcard 



Remarks 



The Comissioner is authorized to charge or credit Deposit Account No. 09-0447. 
Customer No. 34533. 



SIGNATURE OF APPLICANT, ATTORNEY, OR AGENT 



Firm 
or 

Individual name 



John Biggers 
Reg. No. 44,537 




November 30, 2005 



r 


CERTIFICATE OF TRANSMISSION/MAILING 






I hereby certify that this correspondence is being facsimile transmitted to the USPTO or deposited with the United States Postal Service with 
sufficient postage as first class mail in an envelope addressed to: Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on 
the date shown below. 


Typed or printed name 


Catherine Berglund 


^Sig nature 




Date 


November 30, 2005 



This collection of information is required by 37 CFR 1.5. The informatiif! is required to obtain or retain a benefit by the public which is to file (and by the USPTO to 
process) an application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1 .14. This collection is estimated to 2 hours to complete, including 
gathering, preparing, and submitting the completed application form to the USPTO. Time will vary depending upon the individual case. Any comments on the 
amount of time you require to complete this form and/or suggestions for reducing this burden, should be sent to the Chief Information Officer, U.S. Patent and 
Trademark Office, U.S. Department of Commerce, P.O. Box 1450, Alexandria, VA 22313-1450. DO NOT SEND FEES OR COMPLETED FORMS TO THIS 
ADDRESS. SEND TO: Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450. 



if you need assistance in completing the form, call 1-800-PTO-9199 and select option 2. 



BEST AVAILABLE COPY 




AUS920010619US1 
APPEAL BRIEF 



THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Application of: 
William K. Bodin et al. 

Serial No.: 09/881,919 

Filed: June 14, 2001 

Title: Macro Facilities for Direction 
Of Streaming Digital Content 



§ 

§ Group Art Unit: 2154 
§ 

§ Examiner: Patel, Haresh N. 
§ 

§ Arty Docket No.: AUS920010619US1 

§ 
§ 
§ 
§ 



Mail Stop: Appeal Brief-Patents 

Commissioner for Patents 
P.O. Box 1450 

Alexandria, Virginia 223 1 3-1450 



CERTIFICATE OF TRANSMISSION/MAILING 

I hereby certify that this correspondence is being facsimile transmitted to the 
USPTO at 571-273-8300 or deposited with the United States Postal Service 
with sufficient postage as first class mail in an envelope addressed to: 
Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on 
this date: _ . 

Date 



Date v 
Catherine Berglund 0 



APPEAL BRIEF 



Honorable Commissioner: 



This is an Appeal Brief filed pursuant to 37 CFR § 41.37 in response to the Final Office 
Action of June 30, 2005 ('Final Office Action'), and pursuant to the Notice of Appeal 
filed September 30, 2005. 



REAL PARTY IN INTEREST 



The real party in interest is the patent assignee, International Business Machines 
Corporation ("IBM"), a New York corporation having a place of business at Armonk, 
New York 10504. 
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RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

STATUS OF CLAIMS 

Claims 1-27 are pending in the case. All pending claims are on appeal. 

STATUS OF AMENDMENTS 

No amendments were submitted after final rejection. The claims as currently presented 
are included in the Appendix of Claims that accompanies this Appeal Brief. 

SUMMARY OF CLAIMED SUBJECT MATTER 

Applicants provide the following concise summary of the claimed subject matter 
according to 37 CFR§ 41.37(c)(l)(v), including references to the specification with 
paragraph numbers and to the drawings by paragraph numbers. 

Methods, systems, and computer program products are provided for macro control of 
streaming digital content (described for example at paragraph 0074, Figure 5, paragraphs 
0074-0078 and 0083-0089), the method implemented in conjunction with a networked 
system of computers including a content server through which digital content is 
transcoded into streams of multimedia data, the streams communicated via network to 
client devices, the digital content selected for inclusion in streams in dependence upon 
remote director instructions, the remote director instructions comprising hyperlinked 
URLs invoked through a network-capable device, the remote director instructions further 
comprising for each URL in a remote director instruction a computer program that is 
executed when the URL is invoked (described for example at paragraph 0074, Figure 5, 
paragraphs 0074-0078 and 0083-0089), the method comprising the steps of: recording in 
non- volatile, machine-readable storage, the digital content (described for example at 
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paragraph 0075, Figure 5, paragraphs 0074-0078 and 0083-0089); storing in computer 
memory macros, each macro comprising a URL and a first time, the URL being a 
hyperlinked URL component of a remote director instruction, the first time being the time 
when the URL was first invoked through a hyperlink as part of a remote director 
instruction for control of streaming digital content, the macros being stored in the order in 
which the URLs are first invoked through hyperlinks (described for example at paragraph 
0075, Figure 5, paragraphs 0074-0078 and 0083-0089); reading from computer memory 
the macros in the order in which the macros were stored (described for example at 
paragraph 0076, Figure 5, paragraphs 0074-0078 and 0083-0089); invoking each URL of 
each macro as a hyperlink at a second time, the second time being dependent upon the 
first time, invoking each URL further comprising formulating and issuing a remote 
director instruction (described for example at paragraph 0076-0077, Figure 5, paragraphs 
0074-0078 and 0083-0089); retrieving from the no n- volatile, machine-readable storage, 
transcoding, selecting for inclusion in output streams, and communicating to client 
devices, in dependence upon remote director instructions, the digital content (described 
for example at paragraph 0078, Figure 5, paragraphs 0074-0078 and 0083-0089). 

Methods, systems, and computer program products are provided for macro control of 
streaming digital content (described for example at paragraph 0074, Figure 5, paragraphs 
0074-0078 and 0083-0089), the method implemented in conjunction with a system that 
provides streaming digital content from a multiplicity of sources of digital content to a 
multiplicity of client devices, the system including a content server through which digital 
content is transcoded into output streams, the output streams communicated via network 
to client devices, the digital content selected for inclusion in output streams in 
dependence upon remote director instructions, the remote director instructions 
comprising hyperlinked URLs invoked through a network-capable device, the remote 
director instructions further comprising for each URL in an instruction a computer 
program that is executed when the URL is invoked (described for example at paragraph 
0074, Figure 5, paragraphs 0074-0078 and 0083-0089), the method comprising the steps 
of: establishing a first start time for an event, the event comprising a multiplicity of 
sources of digital content, the event having a duration (described for example at 
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paragraph 0083, Figure 5, paragraphs 0074-0078 and 0083-0089); recording in non- 
volatile, machine-readable storage, the digital content (described for example at 
paragraph 0084, Figure 5, paragraphs 0074-0078 and 0083-0089); storing in computer 
memory, during the duration of the event, macros, each macro comprising a URL and a 
first elapsed time, the URL being a hyperlinked URL component of a remote director 
instruction, the first elapsed time being the elapsed time after the first start time when the 
URL was first invoked through a hyperlink as part of a remote director instruction for 
control of streaming digital content, the macros being stored in the order in which the 
URLs are first invoked through hyperlinks (described for example at paragraph 0084, 
Figure 5, paragraphs 0074-0078 and 0083-0089); establishing a second start time for 
retransmitting the event (described for example at paragraph 0085, Figure 5, paragraphs 
0074-0078 and 0083-0089); reading from computer memory the macros in the order in 
which the macros were stored; invoking each URL of each macro as a hyperlink at a 
second elapsed time after the second start time, the second elapsed time being 
approximately equal to the first elapsed time of the macro, invoking each URL further 
comprising issuing a remote director instruction (described for example at paragraph 
0085, Figure 5, paragraphs 0074-0078 and 0083-0089); retrieving from the non-volatile, 
machine-readable storage, transcoding, selecting for inclusion in output streams, and 
communicating to client devices, in dependence upon remote director instructions, the 
digital content (described for example at paragraph 0085, 0087, Figure 5, paragraphs 
0074-0078 and 0083-0089); whereby is effected a retransmission of an event (described 
for example at paragraph 0086, Figure 5, paragraphs 0074-0078 and 0083-0089). 

All such references to the specification identify descriptions and discussions that are part 
of the detailed descriptions of exemplary embodiments of the present invention in the 
present application. Such descriptions and discussions are not limitations of the claims in 
the present application. The only limitations of the claims are set forth in the claims 
themselves. 
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GROUNDS OF REJECTION 

Claims 1-27 in the present application are rejected in the Final Office Action dated June 
30, 2005 for obviousness-type double patenting over claims 1-22 of copending 
Application No. 09/882174, over claims 10-15 of copending Application No. 09/881915, 
over claims 1-20 of copending Application No. 09/881917, and over claims 1-12 of 
copending Application No. 09/882173. As explained in detail below, Applicants 
respectfully traverse the obviousness-type double patenting rejections of the present 
claims. 

Claims 1-27 are in the case. Independent claims 1,7, 10, 16, 19, and 25 stand rejected 
under 35 U.S.C § 103(a) as unpatentable over a first reference entitled Java Media 
Framework API Guide , JMP 2.0 FCS, November 19, 1999, Sun Microsystems, page 1- 
66, 109-135, 173-178 (hereafter 'Sun'), in view of a second reference entitled 
Application Server Solution Guide, Enterprise Edition: Getting Started , Nusbaum, et al., 
May 2000, pages 1-45, 416-434 (hereafter 'Nusbaum'), and in still further view of a third 
reference entitled OpenJava: A Class-based Macro System for Java , Tatsubori, et al 9 July 
2000, In Reflection and Software Engineering, pages 119-135 (hereafter Tatsubori'). As 
explained in detail below, applicants respectfully traverse the rejections of the present 
claims under 35 USC § 103(a). 

ARGUMENT 

REJECTIONS FOR CLAIMS 1-27 BASED ON OBVIOUSNESS-TYPE 
DOUBLE PATENTING ARE IMPROPER 

All claims in the present application are rejected in the Final Office Action for 
obviousness-type double patenting over claims 1-22 of co-pending Application No. 
09/882174, over claims 10-15 of co-pending Application No. 09/881915, over claims 1- 
20 of co-pending Application No. 09/88191 7, and over claims 1-12 of co-pending 
Application No. 09/882173. 



5 



AUS920010619US1 
APPEAL BRIEF 



The law governing double patenting is that the analysis employed in an obviousness-type 
double patenting determination parallels the guidelines for a 35 U.S.C. § 103(a) rejection. 
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966) are applied for establishing a background for determining obviousness under 35 
U.S.C. § 103 and are employed when making an obviousness-type double patenting 
rejection. Manual of Patent Examining Procedure § 804 IIB1. The Graham factual 
inquiries require the Examiner to: 

• determine the scope and content of the art as described in each co-pending 
application; 

• determine the differences between the scope and content of the art as described in 
each co-pending application and the claims at issue; 

• determine the level of ordinary skill in the pertinent art; and 

• evaluate any objective indicia of nonobviousness. 

Co-Pending Application No. 09/882174 

The Final Office Action rejects claims 1-27 for obviousness-type double patenting as 
being unpatentable over 1-22 of co-pending Application No. 09/882174. The Final 
Office Action at page 10 states: 

. . . they are not patentably distinct from each other because the limitations 
of the independent claims 1,7, 10, 16, 19, and 25 are similar to claim 1 of 
copending Application No. 09/882174. The limitations, "remote direction 
of streaming digital content from a content server to a client devices using 
remote director", is equivalent to the use of content information, 
transcoding gateway for providing director instructions to stream digital 
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content, and the use of email containing digital content. The limitations of 
dependent claims 2-6, 8, 9, 1 1 -1 5, 1 7, 1 8, 20-24, 26, 27, are similar to 
claims 2-22 of copending Application No. 09/882174. 

As described above, the Final Office Action must apply the Graham factors to establish 
the required background for a double patenting rejection. Although the Final Office 
Action does not even mention the Graham factors, the Final Office Action at page 10 
states: 

The co-pending application handles transcoding information using the 
network device. The current application also handles transcoding 
information using the network device. The claimed subject matter of the 
copending application does not mention about macro control and macro 
instructions. However, the concept of using macro control and macro 
instructions is well-known in the art, for example, Tatsubori teaches the 
well-known use of macro control and macro instructions (e.g. use of 
metaobjects representing logical entities of a program, page 1). The 
macro control and macro instructions would help provide instructions to 
perform the transcoding for the device. 

Applicants take the assertion in the Final Office Action that co-pending Application No. 
09/882174 "handles transcoding information using the network device" as a 
determination under Graham of the scope and content of the art as described in co- 
pending application No. 09/882174. In response, Applicants note that the Final Office 
Action mischaracterizes co-pending application No. 09/882174 by asserting that the co- 
pending application transcodes information using a network device. Co-pending 
application No. 09/882174 claims a transcoding gateway for "transcoding the digital 
object into a digital file having a digital format and a file name. ..." The scope and 
content of the art as described in co-pending application No. 09/882174 therefore 
includes a transcoding gateway that transcodes a digital object into a digital file having a 
digital format and a file name. The scope and content of the art as described in co- 
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pending application No. 09/882174 does not include any network device that transcodes 
information as asserted in the Final Office Action. Because the Final Office Action does 
not properly determine the scope and content of the art as described in co-pending 
application No. 09/882174, the Final Office Action does not establish the necessary 
background for determining obviousness. Without establishing the necessary background 
for determining obviousness, the Final Office Action cannot support an obviousness-type 
double patenting rejection, and the rejections of claims 1-27 should be withdrawn. 

Applicants take the assertion in the Final Office Action that "[t]he current application 
also handles transcoding information using the network device" and that "[t]he claimed 
subject matter of the co-pending application does not mention about macro control and 
macro instructions" as a determination under Graham of the differences between the 
scope and content of the art as described in co-pending application No. 09/882174 and 
the claims at issue. In response, Applicants note that the Final Office Action 
mischaracterizes the present application by asserting that the present application 
transcodes information using a network device. The present application claims a "content 
server through which digital content is transcoded. . . ." The scope and content of the art 
as described in the present application therefore includes a content server that transcodes 
digital content, not any network device that transcodes information as asserted in the 
Final Office Action. Because the Final Office Action does not properly determine the 
scope and content of the art as described in the present application, the Final Office 
Action cannot determine the differences between the scope and content of the art as 
described in co-pending application No. 09/882174 and the claims at issue. The Final 
Office Action therefore does not establish the necessary background for determining 
obviousness. Without establishing the necessary background for determining 
obviousness, the Final Office Action cannot support an obviousness-type double 
patenting rejection, and the rejections of claims 1-36 should be withdrawn. 

Applicants further assume that the Final Office Action at page 10 attempts to determine 
under Graham the level of ordinary skill in the pertinent art by stating: 
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However, the concept of using macro control and macro instructions is 
well-known in the art, for example, Tatsubori teaches the well-known use 
of macro control and macro instructions (e.g. use of metaobjects 
representing logical entities of a program, page 1). The macro control and 
macro instructions would help provide instructions to perform the 
transcoding for the device. 

The Final Office Action cites page 1 of Tatsubori in an attempt to determine that macro 
control and macro instructions are within the level of ordinary skill in the pertinent art. 
In response, Applicants' respectfully note that page 1 of Tatsubori describes reflection- 
based object oriented macros. Tatsubori' s reflection-based object oriented macros are not 
macros and macro control as claimed in the present application. Because page 1 of 
Tatsubori does not disclose macro and macro controls as claimed in the present 
application, the Final Office Action does not properly establish the level of ordinary skill 
in the pertinent art. The Final Office Action therefore does not establish the necessary 
background for determining obviousness and cannot support an obviousness-type double 
patenting rejection. The rejections of claims 1-27 should be withdrawn. 

Co-Pending Application No. 09/88 1915 

The Final Office Action rejects claims 1-27 for obviousness-type double patenting as 
being unpatentable over claims 10-15 of co-pending Application No. 09/881915. The 
Final Office Action at page 11 states: 

. . . they are not patentably distinct from each other because the limitations of the 
independent claims 1, 7, 10, 16, 19, and 25 are similar to claim 1 of co-pending 
Application No. 09/881915. The limitations, "remote direction of streaming 
digital content from a content server to a client devices using remote director" is 
equivalent to the use of a content server through which digital content is 
transcoded into streams of multimedia data, the streams communicated via 
network to client devices, use of the digital content for streaming, use of remote 
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director instructions comprising hyperlinked URLs invoked through a network- 
capable device. The limitations of dependent claims 2-6, 8, 9, 11-15, 1 7, 1 8, 20- 
24, 26, 27, are similar to claims 2-12 of copending Application No. 09/881915. 

As described above, the Final Office Action must apply the Graham factors to establish 
the required background for a double patenting rejection. Although the Final Office 
Action does not even mention the Graham factors, the Final Office Action does recite the 
same assertions made regarding co-pending Application No. 09/882174 above by stating: 

The co-pending application handles transcoding information using the 
network device. The current application also handles transcoding 
information using the network device. The claimed subject matter of the 
copending application does not mention about macro control and macro 
instructions. However, the concept of using macro control and macro 
instructions is well-known in the art, for example, Tatsubori teaches the 
well-known use of macro control and macro instructions (e.g. use of 
metaobjects representing logical entities of a program, page 1). The 
macro control and macro instructions would help provide instructions to 
perform the transcoding for the device. 

Applicants take such assertions as an attempt to apply the Graham factors regarding this 
co-pending Application No. 09/881915. In response, Applicants note that the Final 
Office Action does not establish the necessary background for determining obviousness 
for the reasons discussed above with regard to co-pending Application No. 09/882174. 
The Final Office Action therefore cannot support an obviousness-type double patenting 
rejection, and the rejections of claims 1-27 should be withdrawn. 
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Co-Pending Application No. 09/88 1917 

The Final Office Action rejects claims 1-27 for obviousness-type double patenting as 
being unpatentable over claims 1-20 of co-pending Application No. 09/881917. The 
Final Office Action at page 12 states: 

. . . they are not patentably distinct from each other because the limitations of the 
independent claims 1, 7, 10 5 16, 19, and 25 are similar to claim 1 of co-pending 
Application No. 09/881917. The limitations, "remote direction of streaming 
digital content from a content server to a client devices using remote director" is 
equivalent to the use of streaming digital content from a multiplicity of sources of 
digital information to a multiplicity of client devices, use of network of digital 
computers comprising a content server. The limitations of dependent claims 2-6, 
8, 9, 11-15, 17, 18, 20-24, 26, 27, are similar to claims 2-20 of copending 
Application No. 09/881917. 

As described above, the Final Office Action must apply the Graham factors to establish 
the required background for a double patenting rejection. Although the Final Office 
Action does not even mention the Graham factors, the Final Office Action does recite the 
same assertions made regarding co-pending Application No. 09/882174 above by stating: 

The co-pending application handles transcoding information using the 
network device. The current application also handles transcoding 
information using the network device. The claimed subject matter of the 
copending application does not mention about macro control and macro 
instructions. However, the concept of using macro control and macro 
instructions is well-known in the art, for example, Tatsubori teaches the 
well-known use of macro control and macro instructions (e.g. use of 
metaobjects representing logical entities of a program, page 1). The 
macro control and macro instructions would help provide instructions to 
perform the transcoding for the device. 

11 



AUS920010619US1 
APPEAL BRIEF 



Applicants take such assertions as an attempt to apply the Graham factors regarding this 
co-pending Application No. 09/881917. In response, Applicants note that the Final 
Office Action does not establish the necessary background for determining obviousness 
for the reasons discussed above with regard to co-pending Application No. 09/882174. 
The Final Office Action therefore cannot support an obviousness-type double patenting 
rejection, and the rejections of claims 1-27 should be withdrawn. 

Co-Pending Application No. 09/882173 

The Final Office Action rejects claims 1-27 for obviousness-type double patenting as 
being unpatentable over claims 1-12 of co-pending Application No. 09/882173. The 
Final Office Action at page 13 states: 

. . . they are not patentably distinct from each other because the limitations of the 
independent claims 1, 7, 10, 16, 19, and 25 are similar to claim 1 of co-pending 
Application No. 09/882173. The limitations, "remote direction of streaming 
digital content from a content server to a client devices using remote director" is 
equivalent to the use of remote direction of streaming digital content from a 
multiplicity of sources of digital information to a multiplicity of client devices 
upon a network of digital computers comprising a content server receiving digital 
content from the sources and the digital content having a multiplicity of digital 
formats. The concept of the use of macro control and macro instructions is well 
known in the art. The limitations of dependent claims 2-6, 8, 9, 11-15, 17, 18, 20- 
24, 26, 27, are similar to claims 2-11 of copending Application No. 09/8821 73. 

As described above, the Final Office Action must apply the Graham factors to establish 
the required background for a double patenting rejection. Although the Final Office 
Action does not even mention the Graham factors, the Final Office Action does recite the 
same assertions made regarding co-pending Application No. 09/882174 above by stating: 
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The co-pending application handles transcoding information using the 
network device. The current application also handles transcoding 
information using the network device. The claimed subject matter of the 
co-pending application does not mention about the broadcasting of user 
controls for streaming. However, broadcasting of user controls for 
streaming is well known in the art, for example, paragraph 4 of the 
Background of the invention section of the specification discloses it. The 
broadcasting related information would help for transcoding by the 
software. 

Applicants take such assertions as an attempt to apply the Graham factors regarding this 
co-pending Application No. 09/882173. In response, Applicants note that the Final 
Office Action does not establish the necessary background for determining obviousness 
for the reasons discussed above with regard to co-pending Application No. 09/882174. 
The Final Office Action therefore cannot support an obviousness-type double patenting 
rejection, and the rejections of claims 1-27 should be withdrawn. 

Conclusion 

The Final Office Action does not establish the necessary background for determining 
obviousness required by an obviousness-type double patenting rejection of claims 1-27 in 
the present application over claims 1-22 of co-pending Application No. 09/882174, over 
claims 10-15 of co-pending Application No. 09/881915, over claims 1-20 of co-pending 
Application No. 09/881917, and over claims 1-12 of co-pending Application No. 
09/882173. Based on the reasoning provided in the Final Office Action, no person of 
ordinary skill in the art would conclude that claims 1-27 in the present case are obvious in 
view of claims 1 -22 of co-pending Application No. 09/882 1 74, over claims 1 0- 1 5 of co- 
pending Application No. 09/881915, over claims 1-20 of co-pending Application No. 
09/881917, and over claims 1-12 of co-pending Application No. 09/882173. Applicants 
therefore respectfully traverse the rejections of claims 1-27 and request reconsideration of 
claims 1-27 in light of the present remarks. 
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REJECTIONS FOR CLAIMS 1-27 BASED ON OBVIOUSNESS 
UNDER 35 U.S.C § 103(a) ARE IMPROPER 



Claims 1-27 are in the case. Independent claims 1,7, 10, 16, 19, and 25 stand rejected 
under 35 U.S.C § 103(a) as unpatentable over a first reference entitled Java Media 
Framework API Guide , JMP 2.0 FCS, November 19, 1999, Sun Microsystems, page 1- 
66, 109-135, 173-178 (hereafter 'Sun'), in view of a second reference entitled 
Application Server Solution Guide, Enterprise Edition: Getting Started , Nusbaum, et al., 
May 2000, pages 1-45, 416-434 (hereafter 'Nusbaum'), in further view of a third 
reference entitled OpenJava: A Class-based Macro System for Java , Tatsubori, et al 9 July 
2000, In Reflection and Software Engineering, pages 119-135 (hereafter Tatsubori'). To 
establish a prima facie case of obviousness, three elements must be proven by the 
Examiner. Manual of Patent Examining Procedure § 2142. The first element of a prima 
facie case of obviousness under 35 U.S.C. § 103 is that the proposed modification or the 
proposed combination of Sun, Nusbaum, and Tatsubori must teach or suggest all of 
applicants' claim limitations. In re Royka, 490 F.2d 981, 985, 180 USPQ 580, 583 
(CCPA 1974). The second element of a prima facie case of obviousness under 35 U.S.C. 
§ 103 is that there must be a suggestion or motivation to modify or to combine Sun, 
Nusbaum, and Tatsubori. In re Vaeck, 947 F.2d 488, 493, 20 USPQ2d 1438, 1442 (Fed. 
Cir. 1991). The third element of a prima facie case of obviousness under 35 U.S.C. § 103 
is that there must be a reasonable expectation of success in the proposed combination of 
Sun, Nusbaum, and Tatsubori. In re Merck & Co., Inc., 800 F.2d 1091, 1097, 231 USPQ 
375, 379 (Fed. Cir. 1986). As demonstrated below, the combination of Sun, Nusbaum, 
and Tatsubori does not establish a prima facie case of obviousness. The rejection of 
claims 1-27 should therefore be withdrawn and the case should be allowed. 
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Sun, Nusbaum. and Tatsubori Do Not Teach 
Each and Every Element of the Independent Claims 

To establish a prima facie case of obviousness, the proposed combination of Sun, 
Nusbaum, and Tatsubori must teach all of applicants' claim limitations. In re Royka, 
490F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). The rejected independent claims 
1,7, 10, 16, 19, and 25 are composed of two sets of independent claims. Independent 
claims 1 of the present application claims: 

1 . A method of macro control of streaming digital content, the 

method implemented in conjunction with a networked system of 
computers including a content server through which digital content 
is transcoded into streams of multimedia data, the streams 
communicated via network to client devices, the digital content 
selected for inclusion in streams in dependence upon remote 
director instructions, the remote director instructions comprising 
hyperlinked URLs invoked through a network-capable device, the 
remote director instructions further comprising for each URL in a 
remote director instruction a computer program that is executed 
when the URL is invoked, the method comprising the steps of: 

recording in non-volatile, machine-readable storage, the digital 
content; 

storing in computer memory macros, each macro comprising a 
URL and a first time, the URL being a hyperlinked URL 
component of a remote director instruction, the first time being the 
time when the URL was first invoked through a hyperlink as part 
of a remote director instruction for control of streaming digital 
content, the macros being stored in the order in which the URLs 
are first invoked through hyperlinks; 
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reading from computer memory the macros in the order in which 
the macros were stored; 

invoking each URL of each macro as a hyperlink at a second time, 
the second time being dependent upon the first time, invoking each 
URL further comprising formulating and issuing a remote director 
instruction; 

retrieving from the non- volatile, machine-readable storage, 
transcoding, selecting for inclusion in output streams, and 
communicating to client devices, in dependence upon remote 
director instructions, the digital content. 

Independent claims 10 and 19 are respective system and computer program product 
claims that correspond to the method of independent claim 1 . Independent claims 7 of 
the present application claims: 

7. A method of macro control of streaming digital content, the 

method implemented in conjunction with a system that provides 
streaming digital content from a multiplicity of sources of digital 
content to a multiplicity of client devices, the system including a 
content server through which digital content is transcoded into 
output streams, the output streams communicated via network to 
client devices, the digital content selected for inclusion in output 
streams in dependence upon remote director instructions, the 
remote director instructions comprising hyperlinked URLs invoked 
through a network-capable device, the remote director instructions 
further comprising for each URL in an instruction a computer 
program that is executed when the URL is invoked, the method 
comprising the steps of: 
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establishing a first start time for an event, the event comprising a 
multiplicity of sources of digital content, the event having a 
duration; 

recording in non- volatile, machine-readable storage, the digital 
content; 

storing in computer memory, during the duration of the event, 
macros, each macro comprising a URL and a first elapsed time, the 
URL being a hyperlinked URL component of a remote director 
instruction, the first elapsed time being the elapsed time after the 
first start time when the URL was first invoked through a 
hyperlink as part of a remote director instruction for control of 
streaming digital content, the macros being stored in the order in 
which the URLs are first invoked through hyperlinks; 

establishing a second start time for retransmitting the event; 

reading from computer memory the macros in the order in which 
the macros were stored; 

invoking each URL of each macro as a hyperlink at a second 
elapsed time after the second start time, the second elapsed time 
being approximately equal to the first elapsed time of the macro, 
invoking each URL further comprising issuing a remote director 
instruction; 

retrieving from the non-volatile, machine-readable storage, 
transcoding, selecting for inclusion in output streams, and 
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communicating to client devices, in dependence upon remote 
director instructions, the digital content; 

whereby is effected a retransmission of an event. 

Independent claims 16 and 25 are respective system and computer program product 
claims that correspond to the method of independent claim 7. In rejecting claims 1,7, 10, 
16, 19, and 25, the Final Office Action at page 15 states that Sun teaches: 

a method, a system and a computer program product to implement 
streaming (e.g., streaming media, page 4) digital content (e.g., MPEG, 
JPEG, etc., video formatted content, page 6), in conjunction with a system 
that provides streaming digital content form a multiplicity of sources of 
digital content (e.g., variety of media sources providing media contents 
over networks, page 3) to a multiplicity of client devices (e.g., media 
content receiving media devices, page 3), the system including a content 
server (e.g., server providing video contents, page 33), into output streams 
(e.g., output stream, page 33), the output streams communicated via 
network to client devices (e.g., media receiving devices across network, 
page 3), the digital content selected for inclusion in output streams in 
dependence upon instructions (e.g., instructions for controlling media 
streams, page 43)... 

That is, the Final Office Action takes the position that Sun at pages 3, 4, 5, 6, 33, and 43 
teaches the following claim elements and limitations from claim 7, which states: 

macro control of streaming digital content, the method implemented in 
conjunction with a system that provides streaming digital content from a 
multiplicity of sources of digital content to a multiplicity of client devices, 
the system including a content server through which digital content is 
transcoded into output streams, the output streams communicated via 
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network to client devices, the digital content selected for inclusion in 
output streams in dependence upon remote director instructions. . . 

What page 3 of Sun actually teaches is a general description of time-based media as 
"[a]ny data that changes meaningfully with respect to time. . and an introduction to the 
chapter that "describes the key characteristics of time-based media and describes the use 
of time-based media in terms of a fundamental data processing model. . .." Page 4 of Sun 
teaches definitions to some common terms used in streaming media including 'content 
type,' 'media stream,' 'multiplex,' 'track,' and so on. Sun at pages 5 teaches that 
"[m]edia streams can be categorized according to how the data is delivered," either using 
a pull protocol or a push protocol. Page 6 of Sun merely discloses a chart of common 
video and audio formats. What page 33 of Sun teaches is a definition of transcoding as a 
"process of converting each track of media data from one input format to another." Sun 
at page 43 teaches a general introduction to the chapter entitled "Presenting Time-Based 
Media with JMF," where ' JMF' stand for Java Media Framework. These cited portions 
of Sun merely provide general descriptions regarding time-based media and how the Java 
Media Framework implements such time-based media. Sun as cited in the Final Office 
Action does not mention, not even once, one word regarding macro control of streaming 
digital content, a content server, remote director instruction, and so on as claimed in the 
present application. Sun at pages 3, 4, 5, 6, 33, and 43 therefore does not teach the 
elements and limitations for macro control of streaming digital content as claimed in the 
present application. The Final Office Action does not produce references that teach each 
and every element of independent claims 1, 7, 10, 16, 19, and 25. The rejections should 
be withdrawn, and the claim should be allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 15 states that 
Sun teaches "establishing a time for an event, the event comprising a multiplicity of 
sources of digital content (e.g., starting the media presentation, page 50)...." Applicants 
take this statement in the Final Office Action as an assertion that page 50 of Sun teaches 
"establishing a first start time for an event. . ." as claimed in claim 7 of the present 
application. What page 50 of Sun actually teaches are application programming 
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interfaces that "define the methods for starting and stopping presentation" of time-based 
media in the Java Media Framework. Sun at page does not mention anything, not one 
word, regarding "establishing a first start time for an event" as claimed in the present 
application. Sun's application programming interface for starting and stopping a time- 
based media presentation does not teach establishing a first start time for an event as 
claimed in the present application. The Final Office Action does not produce references 
that teach each and every element of independent claims 1,7, 10, 16, 19, and 25. The 
rejections should be withdrawn, and the claim should be allowed. 

In rejecting claims 1, 7, 10, 16, 19, and 25, the Final Office Action at page 16 states that 
Sun teaches: 

storing in computer memory, during the duration of the event, function 
comprising a URL and a time (e.g., time based URL information, page 4), 
the URL being a hyperlinked URL component of an instruction (e.g., 
using HTTP protocol, page 4), the first time being the time after the first 
start time when the URL was first invoked though a hyperlink as part of a 
instruction for control of streaming digital content (e.g., handling start 
time of the media information, pages 48 and 50), the functions being 
stored in the order in which the URLs are first invoked through hyperlinks 
and function comprising URL (e.g. sequence of instructions handled for 
handling time based media information, pages 49 and 50)... 

Applicants take this statement in the Final Office Action as an assertion that pages 4, 48, 
49, and 50 of Sun teach the following elements and limitations as claimed in claim 7 of 
the present application: 

storing in computer memory, during the duration of the event, macros, 
each macro comprising a URL and a first elapsed time, the URL being a 
hyperlinked URL component of a remote director instruction, the first 
elapsed time being the elapsed time after the first start time when the URL 
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was first invoked through a hyperlink as part of a remote director 
instruction for control of streaming digital content, the macros being 
stored in the order in which the URLs are first invoked through hyperlinks 

As mentioned above, what page 4 of Sun actually teaches is definitions to some common 
terms used in streaming media including 'content type,' 'media stream,' 'multiplex,' 
'track,' and so on. Page 48 of Sun teaches how to set a start position within the Java 
Media Framework for presenting time-based media. Sun at page 49 teaches how to 
prepare a media player to start a presentation of time-based media using the Java Media 
Framework API. Page 50 of Sun teaches APIs that "define the methods for starting and 
stopping presentation" of time-based media in the Java Media Framework. These cited 
portions of Sun merely provide a general description of common media terms and how to 
start and stop a time-based media presentation using the Java Media Framework API. 
Sun as cited in the Final Office Action does not even mention, among other limitations of 
the claims in the present application, macros, storing macros in computer memory, a first 
elapsed time, a macro that includes a URL and a first elapsed time, remote director 
instructions, and so on. Sun at pages 4, 48, 49, and 50 therefore does not teach the 
elements and limitation for macro control of streaming digital content as claimed in the 
present application. The Final Office Action does not produce references that teach each 
and every element of independent claims 1, 7, 10, 16, 19, and 25. The rejections should 
be withdrawn, and the claim should be allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 16 states that 
Sun teaches "establishing a second time for retransmitting the event (e.g., retransmission 
of the media information if lost or corrupted, page 110)...." Applicants take this 
statement in the Final Office Action as an assertion that page 1 10 of Sun teaches 
"establishing a second start time for retransmitting the event. . as claimed in claim 7 of 
the present application. What page 1 10 of Sun actually teaches is that data packets sent 
using the Transmission Control Protocol ('TCP') are retransmitted when lost or corrupted 
because TCP is a reliable protocol. Page 1 10 of Sun continues to state that TCP is not 
generally used in streaming media because, as a reliable protocol, TCP generally has 
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slower overall transmission rates. Sun at page 110 has nothing to do with establishing a 
second start time for retransmitting the event as claimed in the present application. A 
general description of the TCP protocol does not teach establishing a second start time for 
retransmitting the event as claimed in the present application. The Final Office Action 
does not produce references that teach each and every element of independent claims 1 , 
7, 10, 16, 19, and 25. The rejections should be withdrawn, and the claim should be 
allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 16 states that 
Sun teaches "the event comprising a multiplicity of sources of digital content formats 
(e.g., several media formats, page 6)...." Applicants take this statement in the Final 
Office Action as an assertion that page 6 of Sun teaches "the event comprising a 
multiplicity of sources of digital content, the event having a duration. . as claimed in 
claim 7 of the present application. As mentioned above, page 6 of Sun merely discloses a 
chart of common video and audio formats. A chart of common video and audio formats 
is not an event comprising a multiplicity of sources of digital content, the event having a 
duration as claimed in the present application. Sun at page 6 therefore does not teach an 
event comprising a multiplicity of sources of digital content, the event having a duration 
as claimed in the present application. The Final Office Action does not produce 
references that teach each and every element of independent claims 1, 7, 10, 16, 19, and 
25. The rejections should be withdrawn, and the claim should be allowed. 

In rejecting claims 1, 7, 10, 16, 19, and 25, the Final Office Action at page 16 states that 
Sun teaches "reading from computer memory the functions in the order in which the 
functions were stored (e.g. sequence of functions handled for time based media 
information, pages 49 and 50). . ." Applicants take this statement in the Final Office 
Action as an assertion that pages 49 and 50 of Sun teach "reading from computer 
memory the macros in the order in which the macros were stored. . as claimed in claim 
7 of the present application. As mentioned above, Page 49 of Sun teaches how to prepare 
a media player to start a presentation of time-based media using the Java Media 
Framework API. Sun at page 50 teaches APIs that "define the methods for starting and 
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stopping presentation" of time-based media in the Java Media Framework. The general 
description of how to start and stop a time-based media presentation using the Java Media 
Framework API is not reading from computer memory the macros in the order in which 
the macros were stored as claimed in the present application. Pages 49 and 50 of Sun do 
not mention one word regarding macros, reading macros from computer memory, and 
son on. Sun's general description of how to start and stop a time-based media 
presentation using the Java Media Framework API does not teach reading from computer 
memory the macros in the order in which the macros were stored as claimed in the 
present application. The Final Office Action does not produce references that teach each 
and every element of independent claims 1,7, 10, 16, 19, and 25. The rejections should 
be withdrawn, and the claim should be allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 16 states that 
Sun teaches: 

invoking each URL of each function as a hyperlink at a second elapsed 
time after the second time (e.g., use of sequence of time based URL for 
different functions for controlling the media player to respond several 
media events for playing MPEG movie by synchronized multiple media 
streams from different sources, page 61)... 

That is, the Final Office Action takes the position that Sun at page 61 teaches the 
following elements and limitations in claim 7 of the present application: 

invoking each URL of each macro as a hyperlink at a second elapsed time 
after the second start time, the second elapsed time being approximately 
equal to the first elapsed time of the macro, invoking each URL further 
comprising issuing a remote director instruction 

What Sun at page 61 actually teaches is how to synchronize multiple time-based media 
player implemented using the Java Media Framework API. Page 61 of Sun does not 
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mention URL, invoking each URL, macro, first elapsed time, second elapsed time, and so 
on. Sun's general description of synchronizing multiple time-based media player 
implemented using the Java Media Framework API does not teach invoking each URL of 
each macro as a hyperlink at a second elapsed time after the second start time, the second 
elapsed time being approximately equal to the first elapsed time of the macro, invoking 
each URL further comprising issuing a remote director instruction as claimed in the 
present application. The Final Office Action does not produce references that teach each 
and every element of independent claims 1, 7, 10, 16, 19, and 25. The rejections should 
be withdrawn, and the claim should be allowed. 

In rejecting claims 1, 7, 10, 16, 19, and 25, the Final Office Action at page 17 states that 
Sun teaches: 

retrieving from the non-volatile, machine-readable storage, transcoding, 
selecting for inclusion in output streams, and communicating to client 
devices, in dependence upon instructions, the digital content, whereby is 
effected a retransmission of an event (e.g., retransmission of the media 
information if lost or corrupted, page 110) 

That is, the Final Office Action takes the position that Sun at page 110 teaches "reading 
from computer memory the macros in the order in which the macros were stored" as 
claimed in claim 7 of present application. As mentioned above, page 1 10 of Sun teaches 
that data packets sent using the Transmission Control Protocol ('TCP') are retransmitted 
when lost or corrupted because TCP is a reliable protocol. Page 1 10 of Sun continues to 
state that TCP is not generally used in streaming media because, as a reliable protocol, 
TCP generally has slower overall transmission rates. Sun at page 110 has nothing to do 
with reading from computer memory the macros in the order in which the macros were 
stored as claimed in the present application. Sun at page 110 therefore does not teach 
reading from computer memory the macros in the order in which the macros were stored 
as claimed in the present application. The Final Office Action does not produce 



24 



AUS920010619US1 
APPEAL BRIEF 

references that teach each and every element of independent claims 1, 7, 10, 16, 19, and 
25. The rejections should be withdrawn, and the claim should be allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 17 states that 
Sun teaches: 

the second time being approximately equal to the first elapsed time of the 
function, establishing a first start time for an event, the event having a 
duration, (e.g., setting the playback rate depending upon the elapsed 
timing of the factions compared to the next timing of the event, page 47). 

Applicants take this statement in the Final Office Action as an assertion that page 47 of 
Sun teaches "the second elapsed time being approximately equal to the first elapsed time 
of the macro, invoking each URL further comprising issuing a remote director 
instruction" as claimed in claim 7 of the present application. What page 47 of Sun 
actually teaches is a general description of a 'Player' object in the Java Media Framework 
API and how to set a playback rate for a Player object. The Player object of Java Media 
Framework API and the method which sets the playback rate of the Player object is not 
the second elapsed time being approximately equal to the first elapsed time of the macro, 
invoking each URL further comprising issuing a remote director instruction as claimed in 
the present application. Sun at page 47 therefore does not teach the second elapsed time 
being approximately equal to the first elapsed time of the macro, invoking each URL 
further comprising issuing a remote director instruction as claimed in the present 
application. The Final Office Action does not produce references that teach each and 
every element of independent claims 1, 7, 10, 16, 19, and 25. The rejections should be 
withdrawn, and the claim should be allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 17 states that 
Nusbaum teaches: 
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use of remote director instructions (e.g., use of servlets and JSPs directed 
by clients/administer over network, pages 13 and 36) comprising 
hyperlinked URLs (servlet URLs, page 2) invoked through a network- 
capable device (e.g., network device, page 13) and for each URL in an 
instruction a computer program that is executed when the URL is invoked 
(e.g., servlet to be used specified by the servlet aliases, page 2). 

Applicants take this statement in the Final Office Action as an assertion that pages 2, 13, 
and 36 of Nusbaum teach the following elements and limitations as claimed in claim 7 of 
the present application: 

the remote director instructions comprising hyperlinked URLs invoked 
through a network-capable device, the remote director instructions further 
comprising for each URL in an instruction a computer program that is 
executed when the URL is invoked 

What page 2 of Nusbaum actually teaches is a general description of JavaServlet™. Page 
13 of Nusbaum teaches an Enterprise JavaBean™ environment and its interaction with 
other network components. An Enterprise JavaBeans™ is a server-side object that 
conforms to the Enterprise JavaBeans™ Specification. The EJB specification describes 
the server-side component architecture of the Java 2 Enterprise Edition (' J2EE') platform 
that provides a framework for components to "plug in" to a server and extend that 
server's functionality. Nusbaum at page 36 teaches a "WebSphere Application Server 
Standard Edition 3.0 runtime architecture" and an introduction to the "WebSphere 
Application Server Advanced Edition." Nusbaum' s general description of a 
JavaServlet™, an Enterprise JavaBean™ environment, and descriptions relating to IBM's 
WebSphere products has nothing to do with the remote director instructions as claimed 
in the present application. Pages 2, 13, and 36 of Nusbaum therefore do not teach remote 
director instructions comprising hyperlinked URLs invoked through a network-capable 
device, the remote director instructions further comprising for each URL in an instruction 
a computer program that is executed when the URL is invoked as claimed in the present 
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application. The Final Office Action does not produce references that teach each and 
every element of independent claims 1,7, 10, 16, 19, and 25. The rejections should be 
withdrawn, and the claim should be allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at page 18 states that 
Tatsubori teaches "the well-known use of macro control system and the use of macro to 
perform the functionality of the function (e.g., use of metaobjects representing logical 
entities of a program, page 1)." What page 1 of Tatsubori actually teaches is reflection- 
based object oriented macros. Reflection-based object oriented macros is not macro 
control of streaming digital content as claimed in the present application. In fact, 
reflection-based object oriented macros have nothing to do with the claimed invention. 
The reflection-based object oriented macros of Tatsubori do not teach macro control of 
streaming digital content as claimed in the present application. The Final Office Action 
does not produce references that teach each and every element of independent claims 1 , 
7, 10, 16, 19, and 25. The rejections should be withdrawn, and the claim should be 
allowed. 

In rejecting claims 1,7, 10, 16, 19, and 25, the Final Office Action at pages 15-18 cites 
portions of Sun, Nusbaum, and Tatsubori that have nothing to do with Applicants' 
independent claims. There is not one word in Sun, Nusbaum, or Tatsubori regarding 
macro control of streaming digital content, macros comprising a URL and a first time, 
remote director instructions, macros being stored in the order in which the URLs are first 
invoked through hyperlinks, reading the macros in the order in which the macros were 
stored, invoking each URL of each macro as a hyperlink at a second time, formulating 
and issuing a remote director instruction, and so on, as claimed in the present application. 
The fact that Sun makes general references to streaming media, that Nusbaum makes 
some general references to network communications, or that Tatsubori describes 
reflection based object oriented macros having nothing to do with the claimed invention 
is completely insufficient to anticipate or suggest claim elements in the present 
application. The rejections of claims 1-27 should be withdrawn, and the claims should be 
allowed. 
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The Cited References Set Forth No Suggestion to 
Modify or Combine Sun, Nusbaum, and Tatsubori 

To establish a prima facie case of obviousness, there must be a suggestion or motivation 
to modify or combine Sun, Nusbaum, and Tatsubori. In re Vaeck, 947 F.2d 488, 493, 20 
USPQ2d 1438, 1442 (Fed. Cir. 1991). "The mere fact that references can be combined or 
modified does not render the resultant combination obvious unless the prior art also 
suggests the desirability of the combination." In re Mills, 916 F.2d 680, 16 USPQ2d 
1430 (Fed. Cir. 1990). The Examiner has not pointed to any disclosure in Sun, Nusbaum, 
or Tatsubori suggesting the desirability of the combination. 

Moreover, there is no possibility whatsoever that the Examiner could ever point to any 
disclosure in Sun, Nusbaum, or Tatsubori suggesting the desirability of the combination. 
Sun in fact makes no mention whatsoever of remote director instructions or macro 
control of streaming digital content and therefore could not possibly suggest the 
desirability of the combination. Similarly, Nusbaum makes no mention whatsoever of 
macro control of streaming digital content and therefore could not possibly suggest the 
desirability of the combination. In addition, no such suggestion occurs in Tatsubori. 
Tatsubori presents a discussion of reflection based macros for object oriented execution 
and expresses no concern whatsoever regarding combining them with elements disclosed 
in other references to effect macro control of streaming digital content. 

Absent such a showing of desirability, the Examiner has impermissibly used "hindsight" 
occasioned by Applicants' own teaching to reject the claims. In re Surko, 11 F.3d 887, 
42 U.S.P.Q.2d 1476 (Fed. Cir. 1997); In re Vaeck, 947 F.2d 488m 20 U.S.P.Q.2d 1438 
(Fed. Cir. 1991); In re Gorman, 933 F.2d 982, 986, 18 U.S.P.Q.2d 1885, 1888 (Fed. Cir. 
1991); In re Bond, 910 F.2d 831, 15 U.S.P.Q.2d 1566 (Fed. Cir. 1990); In re Laskowski, 
871 F,.2d 1 15, 1 17, 10 U.S.P.Q.2d 1397, 1398 (Fed. Cir. 1989). Because the Examiner 
has not produced an explicit reference within Sun, Nusbaum, or Tatsubori that suggests 
or implies their combination, the Examiner has impermissibly used hindsight occasioned 
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by Applicants' own teaching to reject the claims. The proposed combination of Sun, 
Nusbaum, and Tatsubori therefore cannot possibly establish a prima facie case of 
obviousness. The rejections should be withdrawn, and the case should be allowed. 

There is No Reasonable Expectation Of Success in the 
Proposed Combination of Sun, Nusbaum, and Tatsubori 

To establish a prima facie case of obviousness, there must be a reasonable expectation of 
success in the proposed combination of Sun, Nusbaum, and Tatsubori. In re Merck & 
Co., Inc., 800 F.2d 1091, 1097, 231 USPQ 375, 379 (Fed. Cir. 1986). The Examiner has 
not pointed to any disclosure in Sun, Nusbaum, and Tatsubori suggesting any expectation 
of success. Absent such a showing of an expectation of success, the Examiner has failed 
to meet one of the three basic elements of a prima facie case of obviousness. 

In addition, there can be no reasonable expectation of success in a proposed combination 
of Sun, Nusbaum, and Tatsubori because Sun, Nusbaum, and Tatsubori cannot be 
combined to provide macro control of streaming digital content as claimed in the present 
invention. The Final Office Action bases this rejection primarily on Sun. Sun is the Java 
Media Framework API Guide , which describes itself in its Preface at page xiii as a 
framework that provides an application programming interface ('API') and a plug-in API 
that enables programmers to develop programs that present time-based media, capture 
and store media data, control the type of processing that is performed during playback, 
and perform custom processing on media data streams. No doubt exist that the Java 
Media Framework API provides helpful features to software developers regarding the 
control of media data streams. Macro control of streaming digital content as claimed in 
the present application, however, is not a feature provided by the Java Media Framework 
API. As described above, Tatsubori teaches reflective-based object oriented macros that 
have nothing to do with the macros and macro control of the present application. 
Nusbaum teachs an EJB execution environment and a kind of dynamic web page 
technology known as Java Server Pages or 'JSP' As described in Nusbaum, dynamic 
web page technology is methods and systems for building server pages on the fly. 
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Dynamic web pages generally, and JSPs in particular, is not streaming media. Sun's Java 
Media Framework API, Nusbaum's dynamic web page technology, and Tatsubori's 
reflective-based object oriented macros does not combine to provide macro control of 
streaming digital content as claimed in the present application. The proposed 
combination of Sun, Nusbaum, and Tatsubori therefore cannot support a prima facie case 
of obviousness. The rejections should be withdrawn, and the case should be allowed. 

Sun Teaches Away From the 
Claims of the Present Application 

Turning now to the substance of Sun, Sun actually teaches away from the current 
application. Teaching away from the claims is a per se demonstration of lack of prima 
facie obviousness. In re Dow Chemical Co., 837 F.2d 469, 5 U.S.P.Q.2d 1529 (Fed. Cir. 
1988); In re Fine, 837 F.2d 1071, 5 U.S.P.Q.2d 1596 (Fed. Cir. 1988); In re Neilson, 816 
F.2d 1567, 2 U.S.P.Q.2d 1525 (Fed. Cir. 1987). Sun discloses an API that enables 
programmers to develop programs that present time-based media, capture and store 
media data, control the type of processing that is performed during playback, and perform 
custom processing on media data streams. Clearly there would be no impulse on the part 
of the developers of the Sun's Java Media Framework API to incorporate macro control 
of streaming digital content as claimed in the present application. By disclosing the Java 
Media Framework API features and functions alone, with no hint or suggestion that 
macro control of streaming digital content as claimed in the present application might 
even exist, Sun teaches away from the macro control of streaming digital content as 
claimed in the present application. Because Sun teaches away from the Applicants 
claims, the proposed combination of Sun with Nusbaum and Tatsubori cannot support a 
prima facie case of obviousness. The rejection of Applicants' claims should be 
withdrawn and the case should be allowed. 
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Sun Cannot be a Reference Against the Claims of the Present 
Application Because Sun Represents Nonanalogous Art 

Sun cannot be a reference against the claims of the present application because Sun 
represents nonanalogous art within the meaning of In Re Horn, Clay, and Oeitker, In re 
Horn, 203 USPQ 969 (CCPA 1979), In re Clay, 966 F.2d 656, 23 USPQ2d 1058 (Fed. 
Cir. 1992), In re Oeticker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). The field . 
of the inventors' effort in this case is macro control of streaming digital content. The 
present application claims, among other things, macros comprising a URL and a first 
time, remote director instructions, macros being stored in the order in which the URLs 
are first invoked through hyperlinks, reading the macros in the order in which the macros 
were stored, invoking each URL of each macro as a hyperlink at a second time, 
formulating and issuing a remote director instruction, and so on, as claimed in the present 
application. The field of Sun is a Java framework that present an API, a particular API 
that enables programmers to develop programs that present time-based media, capture 
and store media data, control the type of processing that is performed during playback, 
and perform custom processing on media data streams - clearly having nothing to do 
with the technical field of the present application. Sun therefore is not within the field of 
the inventor's endeavor in this case. 

Because Sun is not within the field of the inventor's endeavor in this case, there can be no 
basis for believing that Sun as a reference would have been considered by one skilled in 
the particular art working on the relevant problem to which this invention pertains. That 
is, there would be no reason for an inventor concerned with macro control of streaming 
digital content to search for art regarding Sun's Java Media Framework API, which has 
no operability or functionality related to macro controls. The two simply have nothing to 
do with one another. Sun as a reference therefore is not reasonably pertinent to the 
particular problem with which the inventors were involved in the present case and is not 
available as a reference against the present application. Applicants respectfully propose 
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that for this reason alone the rejection of the present claims should be withdrawn, and the 
claims should be allowed. 

Conclusion 

All claims in the present case stand rejected under 35 U.S.C § 103(a). Independent 
claims 1, 7, 10, 16, 19, and 25 stand rejected under 35 U.S.C § 103(a) over Sun in view 
of Nusbaum further in view of Tatsubori. The combination of Sun, Nusbaum, and 
Tatsubori fails to establish a prima face case of obviousness. The applicants have 
demonstrated that it is incorrect to reject the independent claims 1, 7 5 10, 16, 19, and 25 
under 35 U.S.C § 103(a). The dependent claims of the present application include each 
and every element and limitation of the independent claims from which they depend. 
Because the Final Office Action cites only the combination of Sun, Nusbaum, and 
Tatsubori to teach or suggest each and every element of the independent claims and 
because all the independent claims stand, Applicants respectfully propose that all the 
dependent claims in the present case stand. The rejection of all the claims 1-27 should 
therefore be withdrawn, and the claims should be allowed. Applicants respectfully 
traverse the rejection of claims 1-27 and request reconsideration of claims 1-27 in light of 
the present remarks. 

APPPLICANTS' RESPONSE TO EXAMINER'S RESPONSE TO APPLICANTS' 
RESPONSE TO THE FIRST OFFICE ACTION DATED SEPTEMBER 24, 2004 

The Final Office Action responds to Applicants' Response to First Office Action of 
September 24, 2004 ("First Office Action") with the following arguments. First, Sun, 
Nusbaum, and Tatsubori set forth a suggestion or motivation to combine Sun, Nusbaum, 
and Tatsubori. Second, there is a reasonable expectation of success in the combination of 
Sun, Nusbaum, and Tatsubori. Third, Sun, Nusbaum, and Tatsubori teach or suggest each 
and every element and limitation of the Applicants' claims. Finally, Sun is analogous art 
because it is in the field of Applicants' endeavor or reasonably pertinent to the particular 
problem with which the Applicants were concerned. Applicants respectfully traverse 
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each of the responses in the Final Office Action to Applicants' Response to the First 
Office Action and respond below in detail to the new arguments set forth in the Final 
Office Action. 

The Cited References Set Forth No Suggestion Or 
Motivation To Combine Sun, Nusbaum, And Tatsubori 

The Final Office Action at pages 2-4 argues that Sun, Nusbaum, and Tatsubori are 
properly combined for an obviousness rejection under 35 U.S.C. § 103 on the grounds 
that: 

Sun teaches a method, a system and a computer program product to 
implement streaming (e.g., streaming media, page 4) digital content (e.g., 
MPEG, JPEG, etc., video formatted content, page 6), in conjunction with a 
system that provides streaming digital content form a multiplicity of 
sources of digital content (e.g., variety of media sources providing media 
contents over networks, page 3) to a multiplicity of client devices (e.g., 
media content receiving media device, page 3), the system including a 
content server (e.g., server providing video contents, page 5) through 
which digital content is transcoded (e.g., transcoding the video contents , 
page 33), into output streams (e.g., output stream, page 33), the output 
streams communicated via network to client devices (e.g., media receiving 
devices across network, page 3), the digital content selected for inclusion 
in output streams in dependence upon instructions (e.g., instructions for 
controlling media streams, page43). Nusbaum teaches use of remote 
director instructions (e.g., use of servlets and JSPs directed by 
clients/administer over network, pages 13 and 36) comprising hyperlinked 
URLs (servlets URLs, page 2) invoked through a network-capable device 
(e.g., network device, page 13) and for each URL in an instruction a 
computer program that is executed when the URL is invoked (e.g, servlet 
to be used specified by the servlet aliases, page 2). Tatsubori teaches the 
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well-known use of macro control system and the use of macro to perform 
the functionality of the function (e.g., use of meta objects representing 
logical entities of a program, page 1). 

That is, the Final Office Action responds to Applicants' argument that there is no 
suggestion or motivation to combine Sun, Nusbaum, and Tatsubori by stating that Sun, 
Nusbaum, and Tatsubori teach various elements and limitations of the independent 
claims. As explained in detail above, the cited references in fact do not teach macro 
control of streaming digital content as claimed in the present application. Nusbaum 
generally teaches a kind of dynamic web page technology known as Java Server Pages. 
Sun generally teaches the Java Media API, an application programming interface for 
delivery of time-based media. Tatsubori generally describes reflection based object 
oriented macros nothing to do with the claimed invention. Not only do the cited portions 
of the references fail to disclose or suggest elements of the present claims, even if they 
did so, the Final Office Action cannot arbitrarily pick and choose with massive hindsight 
elements of Applicants' claims from the Java Media API, Java Server Pages, and 
reflection-based object oriented macros and use them as a basis to conclude the present 
claims invalid for obviousness. For these reasons, Applicants continue to assert that there 
is no suggestion or motivation to combine Sun, Nusbaum, and Tatsubori. The proposed 
combination of Sun, Nusbaum, and Tatsubori therefore cannot support a prima facie case 
of obviousness. The rejections to claims 1-27 should be withdrawn, and the case should 
be allowed. 

The Final Office Action at page 2 citing In re Keller, 642 R2d 413, 425, 208 USPQ 871, 
881 (CCPA 1981) and In re Young, 927 F.2d 588, 591 18 USPQ2d 1089, 1091 (Fed. Cir. 
1 99 1 ), also argues that: 

the test for obviousness is not whether the features of a secondary 
reference may be bodily incorporated into the structure of a primary 
reference. It is also not that the claimed invention must be expressly 
suggested in any one or all of the references. Rather, the test is what the 
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combined teachings of the references would have suggested to those of 
skill in the art. 

In this way, the Final Office Action implicitly argues that there is no need for the 
Examiner to demonstrate that the references provide motivation or suggestion to combine 
or that there is any reasonable expectation of success in combining the references so long 
as elements of the present claims are disclosed in the references. 

As the Commissioner is well aware, however, such is not the law. The mere fact that 
references can be combined or modified does not render the resultant combination 
obvious unless the prior art also suggests the desirability of the combination. In re Mills, 
916 F.2d 680, 16 USPQ2d 1430 (Fed. Cir. 1990). In fact, the requirement of a prima 
facie case of obviousness places a burden on the Examiner to provide some suggestion of 
the desirability of doing what the inventor has done. "To support the conclusion that the 
claimed invention is directed to obvious subject matter, either the references must 
expressly or impliedly suggest the claimed invention or the examiner must present a 
convincing line of reasoning as to why the artisan would have found the claimed 
invention to have been obvious in light of the teachings of the references." Ex parte 
Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985). When the motivation to 
combine the teachings of the references is not immediately apparent, it is the duty of the 
examiner to explain why the combination of the teachings is proper. Ex parte Skinner, 2 
USPQ2d 1788 (Bd. Pat. App. & Inter. 1986); MPEP § 2142. 

The Final Office Action merely continues the practice begun in the First Office Action of 
pointing to elements of method and system in its cited references and stating that they are 
the same things claimed in the present patent application. The Final Office Action makes 
no substantive attempt whatsoever to present a prima facie case of obviousness by 
pointing to express or implicit suggestion to combine in the references themselves or by 
explaining or providing any basis for concluding that persons of skill in the art would be 
moved to combine the references. For these reasons also, Applicants continue to assert 
that the cited references do not contain a suggestion or motivation to combine. The 
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proposed combination of Sun, Nusbaum, and Tatsubori therefore cannot support a prima 
facie case of obviousness. The rejections to claims 1-27 should be withdrawn, and the 
case should be allowed. 



There Is No Reasonable Expectation Of Success In The 
Combination Of Sun, Nusbaum, And Tatsubori 



In response to Applicants' Response to the First Office Action, the Final Office Action at 
pages 4 and 5 argues that there is a reasonable expectation of success in the combination 
of Sun, Nusbaum, and Tatsubori. The Final Office Action does not, however, provide 
any new basis for this assertion other than stating that Sun, Nusbaum, and Tatsubori teach 
various elements and limitations of the independent claims. As explained in detail above, 
the cited references in fact do not teach macro control of streaming digital content as 
claimed in the present application. Nusbaum generally teaches a kind of dynamic web 
page technology known as Java Server Pages. Sun generally teaches the Java Media API, 
an application programming interface for delivery of time-based media. Tatsubori 
generally describes reflection based object oriented macros nothing to do with the 
claimed invention. The dynamic web page technology of Nusbaum for building adhoc 
server pages is not related to the Java API for time-based media of Sun. In fact, the 
technology for building dynamic web pages is entirely different from a Java API for time- 
based media. JSPs generate documents viewable in a web browser, while the API for 
time-based media provide a Java class architecture to software developers. Combining 
Nusbaum's Java Server Pages, Sun's Java Media API, Tatsubori 's reflection-based object 
oriented macros does not provide macro control of streaming digital content as claimed in 
the present application. For these reasons, Applicants continue to assert that there is 
therefore no reasonable expectation of success in the proposed combination of Sun, 
Nusbaum, and Tatsubori. The proposed combination of Sun, Nusbaum, and Tatsubori 
therefore cannot support a prima facie case of obviousness. The rejections to claims 1-27 
should be withdrawn, and the case should be allowed. 
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Sun, Nusbaunu And Tatsubori Do Not Teach 
Each and Every Element of the Claims 

The Final Office Action at pages 6 and 7 again argues that Sun, Nusbaum, and Tatsubori 
teach each and every element of independent claims 1, 7, 10, 16, 19, and 25 by reciting 
portions of Sun, Nusbaum, and Tatsubori mentioned above in this Brief. To establish a 
prima facie case of obviousness, the proposed combination of Sun, Nusbaum, and 
Tatsubori must teach all of Applicants' claim limitations. In re Royka, 490F.2d 981, 985, 
180 USPQ 580, 583 (CCPA 1974). As discussed in detail above, the combination of 
Sun, Nusbaum, and Tatsubori does not teach each and every element of the independent 
claims in the present case. The Final Office Action therefore cannot establish a prima 
facie case for obviousness of claims 1, 7, 10, 16, 19, and 25 under 35 U.S.C. § 103. The 
dependent claims of the present application include each and every element and 
limitation of the independent claims from which they depend. Because the Final Office 
Action cites only the combination of Sun, Nusbaum, and Tatsubori to teach or suggest 
each and every element of the independent claims and because all the independent claims 
stand, Applicants respectfully propose that all the dependent claims in the present case 
stand. The proposed combination of Sun, Nusbaum, and Tatsubori therefore cannot 
support a prima facie case of obviousness. The rejections to claims 1-27 should be 
withdrawn, and the case should be allowed. 

Sun Is Not Analogous Art Because It Is Neither In The Field Of Applicants' 
Endeavor Nor Reasonably Pertinent To The Particular Problem 
With Which The Applicants Were Concerned 

In response to Applicants' First Office Action, the Final Office Action at pages 7-9 
argues that Sun is analogous art available for rejecting the claims of the present 
application. The Final Office Action asserts that Sun is in the field of Applicants' 
endeavor or reasonably pertinent to the particular problem with which the Applicants 
were concerned. In support for this assertion, the Final Office Action at page 7-9 only 
states that Sun, Nusbaum, and Tatsubori teach various elements and limitations of the 
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independent claims. As explained in detail above, the cited references in fact do not 
teach macro control of streaming digital content as claimed in the present application. 
Nusbaum generally teaches a kind of dynamic web page technology known as Java 
Server Pages. Sun generally teaches the Java Media API, an application programming 
interface for delivery of time-based media. Tatsubori generally describes reflection based 
object oriented macros nothing to do with the claimed invention. Without more, Sun's 
Java Media API does not place Sun in the field of Applicants' endeavor or make Sun 
reasonably pertinent to the particular problem with which the Applicants were concerned, 
such concern being, macro control of streaming digital content as claimed in the present 
application. 

In addition, Applicants respectfully propose that Sun cannot be a reference against the 
claims of the present application because Sun represents nonanalogous art within the 
meaning of In Re Horn, Clay, and Oeitker. In re Horn, 203 USPQ 969 (CCPA 1 979), In 
re Clay, 966 F.2d 656, 23 USPQ2d 1058 (Fed. Cir. 1992), In re Oeticker, 977 F.2d 1443, 
24 USPQ2d 1443 (Fed. Cir. 1992). The field of the inventors' effort in this case is macro 
control of streaming digital content. The present application claims, among other things, 
macros comprising a URL and a first time, remote director instructions, macros being 
stored in the order in which the URLs are first invoked through hyperlinks, reading the 
macros in the order in which the macros were stored, invoking each URL of each macro 
as a hyperlink at a second time, formulating and issuing a remote director instruction, and 
so on, as claimed in the present application. The field of Sun is a Java framework that 
present an API, a particular API that enables programmers to develop programs that 
present time-based media, capture and store media data, control the type of processing 
that is performed during playback, and perform custom processing on media data streams 
- clearly having nothing to do with the technical field of the present application and not 
reasonably pertinent to the particular problem with which the inventors were involved in 
the present case. Sun therefore is not within the field of the inventor's endeavor in this 
case. 
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Because Sun is neither within the field of the inventor's endeavor in this case nor 
reasonably pertinent to the particular problem with which the inventors were involved in 
the present case, there can be no basis for believing that Sun as a reference would have 
been considered by one skilled in the particular art working on the relevant problem to 
which this invention pertains. That is, there would be no reason for an inventor 
concerned with macro control of streaming digital content to search for art regarding 
Sun's Java Media Framework API, which has no operability or functionality related to 
macro controls. The two simply have nothing to do with one another. Sun as a reference 
therefore is neither within the field of the Applicants' endeavor nor reasonably pertinent 
to the particular problem with which the inventors were involved in the present case and 
is not available as a reference against the present application. Applicants respectfully 
propose that for this reason alone the rejection of the present claims should be withdrawn, 
and the claims should be allowed. 



Conclusion 



Applicants traverse each of the arguments in the Final Office Action responding to 
Applicants' Response to First Office Action. Applicants demonstrate that the cited 
references in the Final Office Action set forth neither a suggestion nor motivation to 
combine Sun, Nusbaum, and Tatsubori. Furthermore, there is no reasonable expectation 
of success in the combination of Sun, Nusbaum, and Tatsubori. In addition, Sun, 
Nusbaum, and Tatsubori do not teach or suggest each and every element and limitation of 
the Applicants' claims. Applicants also demonstrate that Sun represents nonanalogous 
art. Applicants' therefore respectfully traverse each rejection individually of claims 1-27. 
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In view of the forgoing arguments, reversal on all grounds of rejection is requested. 

The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 
for any fees required or overpaid. 



Date: November 30. 2005 



ectfully submitted, 




John Biggers 
Reg. No. 44,537 
Biggers & Ohanian, LLP 
P.O. Box 1469 
Austin, Texas 78767-1469 
Tel. (512) 472-9881 
Fax (512) 472-9887 
ATTORNEY FOR APPELLANTS 
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APPENDIX OF CLAIMS 
ON APPEAL IN PATENT APPLICATION OF 
WILLIAM K. BODIN, ETAL., SERIAL NO. 09/881,919 

CLAIMS 

What is claimed is: 

1 . A method of macro control of streaming digital content, the method implemented 
in conjunction with a networked system of computers including a content server 
through which digital content is transcoded into streams of multimedia data, the 
streams communicated via network to client devices, the digital content selected 
for inclusion in streams in dependence upon remote director instructions, the 
remote director instructions comprising hyperlinked URLs invoked through a 
network-capable device, the remote director instructions further comprising for 
each URL in a remote director instruction a computer program that is executed 
when the URL is invoked, the method comprising the steps of: 

recording in non-volatile, machine-readable storage, the digital content; 

storing in computer memory macros, each macro comprising a URL and a first 
time, the URL being a hyperlinked URL component of a remote director 
instruction, the first time being the time when the URL was first invoked through 
a hyperlink as part of a remote director instruction for control of streaming digital 
content, the macros being stored in the order in which the URLs are first invoked 
through hyperlinks; 

reading from computer memory the macros in the order in which the macros were 
stored; 
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invoking each URL of each macro as a hyperlink at a second time, the second 
time being dependent upon the first time, invoking each URL further comprising 
formulating and issuing a remote director instruction; 



retrieving from the non-volatile, machine-readable storage, transcoding, selecting 
for inclusion in output streams, and communicating to client devices, in 
dependence upon remote director instructions, the digital content. 

2. The method of claim 1 wherein recording the digital content further comprises 
recording approximately an original raw form of the digital content. 

3. The method of claim 1 wherein issuing a remote director instruction further 
comprises executing upon a content server through a Java servlet within the 
content server computer programs identified by the URLs. 

4. The method of claim 3 wherein the computer programs comprise Java thread- 
level URL dispatch routines. 

5. The method of claim 1 wherein the transcoding, selecting for inclusion in output 
streams, and communicating to client devices are all carried out in dependence 
upon user preferences, user demographics, and client device attributes. 

6. The method of claim 1 wherein the transcoding, selecting for inclusion in output 
streams, and communicating to client devices are all carried out in dependence 
upon current real time remote director instructions received from a director 
coupled to the content server through a servlet within the content server. 

7. A method of macro control of streaming digital content, the method implemented 
in conjunction with a system that provides streaming digital content from a 
multiplicity of sources of digital content to a multiplicity of client devices, the 
system including a content server through which digital content is transcoded into 

42 



AUS920010619US1 
APPEAL BRIEF 

output streams, the output streams communicated via network to client devices, 
the digital content selected for inclusion in output streams in dependence upon 
remote director instructions, the remote director instructions comprising 
hyperlinked URLs invoked through a network-capable device, the remote director 
instructions further comprising for each URL in an instruction a computer 
program that is executed when the URL is invoked, the method comprising the 
steps of: 

establishing a first start time for an event, the event comprising a multiplicity of 
sources of digital content, the event having a duration; 

recording in non- volatile, machine-readable storage, the digital content; 

storing in computer memory, during the duration of the event, macros, each 
macro comprising a URL and a first elapsed time, the URL being a hyperlinked 
URL component of a remote director instruction, the first elapsed time being the 
elapsed time after the first start time when the URL was first invoked through a 
hyperlink as part of a remote director instruction for control of streaming digital 
content, the macros being stored in the order in which the URLs are first invoked 
through hyperlinks; 

establishing a second start time for retransmitting the event; 

reading from computer memory the macros in the order in which the macros were 
stored; 

invoking each URL of each macro as a hyperlink at a second elapsed time after 
the second start time, the second elapsed time being approximately equal to the 
first elapsed time of the macro, invoking each URL further comprising issuing a 
remote director instruction; 
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retrieving from the non-volatile, machine-readable storage, transcoding, selecting 
for inclusion in output streams, and communicating to client devices, in 
dependence upon remote director instructions, the digital content; 

whereby is effected a retransmission of an event. 

The method of claim 7 further comprising the steps of: 

registering a user for a retransmission of an event, the retransmission of an event 
identified by an event identification code, the retransmission of an event 
comprising at least one video stream, at least one source, a start date and a start 
time; 

logging in the user for the retransmission of an event, logging in the user further 
comprising assigning values to user login attributes, the user login attributes 
comprising user identification, device type, network address, and a tier; 

assigning a tier value in dependence upon the device type and the event 
identification code; 

wherein the selections are dependent upon the tier; 

wherein transcoding further comprises transcoding in dependence upon the tier; 
and 

wherein communicating to at least one of the client devices the output video 
stream further comprises communicating the output video stream to the network 
address. 

The method of claim 7 wherein: 



44 



AUS920010619US1 
APPEAL BRIEF 

registering a user further comprises creating an event registration record 
comprising event registration attributes comprising user id, event id, event 
subscription level, start date, and start time; and 

assigning a tier value further comprises assigning a tier value in dependence upon 
the event subscription level. 

A system for macro control of streaming digital content, the system implemented 
in conjunction with a computer network including a content server through which 
digital content is transcoded into streams of multimedia data, the streams 
communicated via network to client devices, the digital content selected for 
inclusion in streams in dependence upon remote director instructions, the remote 
director instructions comprising hyperlinked URLs invoked through a network- 
capable device, the remote director instructions further comprising for each URL 
in a remote director instruction a computer program that is executed when the 
URL is invoked, the system comprising: 

means for recording in non- volatile, machine-readable storage, the digital content. 

means for storing in computer memory macros, each macro comprising a URL 
and a first time, the URL being a hyperlinked URL component of a remote 
director instruction, the first time being the time when the URL was first invoked 
through a hyperlink as part of a remote director instruction for control of 
streaming digital content, the macros being stored in the order in which the URLs 
are first invoked through hyperlinks; 

means for reading from computer memory the macros in the order in . which the 
macros were stored; 

means for invoking each URL of each macro as a hyperlink at a second time, the 
second time being dependent upon the first time, means for invoking each URL 
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further comprising means for formulating and means for issuing a remote director 
instruction; 

means for retrieving from the non-volatile, machine-readable storage, means for 
transcoding, means for selecting for inclusion in output streams, and means for 
communicating to client devices, in dependence upon remote director 
instructions, the digital content. 

1 1 . The system of claim 1 0 wherein means for recording the digital content further 
comprises means for recording approximately the original raw form of the digital 
content. 

12. The system of claim 10 wherein means for issuing a remote director instruction 
further comprises means for executing upon a content server through a Java 
servlet within the content server computer programs identified by the URLs. 

13. The system of claim 12 wherein the computer programs comprise Java thread- 
level URL dispatch routines. 

14. The system of claim 10 wherein the means for transcoding, means for selecting 
for inclusion in output streams, and means for communicating to client devices 
are all implemented in dependence upon user preferences, user demographics, and 
client device attributes. 

15. The system of claim 10 wherein the means for transcoding, means for selecting 
for inclusion in output streams, and means for communicating to client devices 
are all implemented in dependence upon current real time remote director 
instructions received from a director coupled to the content server through a 
servlet within the content server. 

16. A system for macro control of streaming digital content, the system implemented 
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in conjunction with a content server that provides streaming digital content from a 
multiplicity of sources of digital content to a multiplicity of client devices, the 
digital content transcoded into output streams, the output streams communicated 
via network to client devices, the digital content selected for inclusion in output 
streams in dependence upon remote director instructions, the remote director 
instructions comprising hyperlinked URLs invoked through a network-capable 
device, the remote director instructions further comprising for each URL in an 
instruction a computer program that is executed when the URL is invoked, the 
system comprising: 

means for establishing a first start time for an event, the event comprising a 
multiplicity of sources of digital content, the event having a duration; 

means for recording in non- volatile, machine-readable storage, the digital content; 

means for storing in computer memory, during the duration of the event, macros, 
each macro comprising a URL and a first elapsed time, the URL being a 
hyperlinked URL component of a remote director instruction, the first elapsed 
time being the elapsed time after the first start time when the URL was first 
invoked through a hyperlink as part of a remote director instruction for control of 
streaming digital content, the macros being stored in the order in which the URLs 
are first invoked through hyperlinks; 

means for establishing a second start time for retransmitting the event; 

means for reading from computer memory the macros in the order in which the 
macros were stored; 

means for invoking each URL of each macro as a hyperlink at a second elapsed 
time after the second start time, the second elapsed time being approximately 
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equal to the first elapsed time of the macro, means for invoking each URL further 
comprising means for issuing a remote director instruction; 

means for retrieving from the non-volatile, machine-readable storage, means for 
transcoding, means for selecting for inclusion in output streams, and means for 
communicating to client devices, in dependence upon remote director 
instructions, the digital content. 

The system of claim 16 further comprising: 

means for registering a user for a retransmission of an event, the retransmission of 
an event identified by an event identification code, the retransmission of an event 
comprising at least one video stream, at least one source, a start date and a start 
time; 

means for logging in a user for the retransmission of an event, means for logging 
in a user further comprising means for assigning values to user login attributes, 
the user login attributes comprising user identification, device type, network 
address, and a tier; 

means for assigning a tier value in dependence upon the device type and the event 
identification code; 

wherein the selections are dependent upon the tier; 

wherein means for transcoding further comprises means for transcoding in 
dependence upon the tier; and 

wherein means for communicating to at least one of the client devices the output 
video stream further comprises means for communicating the output video stream 
to the network address. 
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18. The system of claim 1 7 wherein: 

means for registering a user further comprises means for creating an event 
registration record comprising event registration attributes including comprising 
user identification, event identification, event subscription level, start date, and 
start time; and 

means for assigning a tier value further comprises means for assigning a tier value 
in dependence upon the event subscription level. 

1 9. A computer program product for macro control of streaming digital content, the 
computer program product implemented in conjunction with a computer network 
including a content server through which digital content is transcoded into 
streams of multimedia data, the streams communicated via network to client 
devices, the digital content selected for inclusion in streams in dependence upon 
remote director instructions, the remote director instructions comprising 
hyperlinked URLs invoked through a network-capable device, the remote director 
instructions further comprising for each URL in a remote director instruction a 
computer program that is executed when the URL is invoked, the computer 
program product comprising: 

a recording medium; 

means, recorded upon the recording medium, for recording in non-volatile, 
machine-readable storage, the digital content; 

means, recorded upon the recording medium, for storing in computer memory 
macros, each macro comprising a URL and a first time, the URL being a 
hyperlinked URL component of a remote director instruction, the first time being 
the time when the URL was first invoked through a hyperlink as part of a remote 
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director instruction for control of streaming digital content, the macros being 
stored in the order in which the URLs are first invoked through hyperlinks; 

means, recorded upon the recording medium, for reading from computer memory 
the macros in the order in which the macros were stored; 



means, recorded upon the recording medium, for invoking each URL of each 
macro as a hyperlink at a second time, the second time being dependent upon the 
first time, means for invoking each URL further comprising means for 
formulating and means for issuing a remote director instruction; 



means, recorded upon the recording medium, for retrieving from the non-volatile, 
machine-readable storage, means for transcoding, means for selecting for 
inclusion in output streams, and means for communicating to client devices, in 
dependence upon remote director instructions, the digital content. 

20. The computer program product of claim 1 9 wherein means for recording the 
digital content further comprises means for recording approximately the original 
raw form of the digital content. 

2 1 . The computer program product of claim 1 9 wherein means for issuing a remote 
director instruction further comprises means for executing upon a content server 
through a Java servlet within the content server computer programs identified by 
the URLs. 

22. The computer program product of claim 2 1 wherein the computer programs 
comprise Java thread-level URL dispatch routines. 

23. The computer program product of claim 19 wherein the means for transcoding, 
means for selecting for inclusion in output streams, and means for communicating 
to client devices are all implemented in dependence upon user preferences, user 
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demographics, and client device attributes. 

24. The computer program product of claim 19 wherein the means for transcoding, 
means for selecting for inclusion in output streams, and means for communicating 
to client devices are all implemented in dependence upon current real time remote 
director instructions received from a director coupled to the content server 
through a servlet within the content server. 

25. A computer program product for macro control of streaming digital content, the 
computer program product implemented in conjunction with a content server that 
provides streaming digital content from a multiplicity of sources of digital content 
to a multiplicity of client devices, the digital content transcoded into output 
streams, the output streams communicated via network to client devices, the 
digital content selected for inclusion in output streams in dependence upon remote 
director instructions, the remote director instructions comprising hyperlinked 
URLs invoked through a network-capable device, the remote director instructions 
further comprising for each URL in an instruction a computer program that is 
executed when the URL is invoked, the computer program product comprising: 

a recording medium; 

means, recorded upon the recording medium, for establishing a first start time for 
an event, the event comprising a multiplicity of sources of digital content, the 
event having a duration; 

means, recorded upon the recording medium, for recording in non- volatile, 
machine-readable storage, the digital content; 

means, recorded upon the recording medium, for storing in computer memory, 
during the duration of the event, macros, each macro comprising a URL and a 
first elapsed time, the URL being a hyperlinked URL component of a remote 
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director instruction, the first elapsed time being the elapsed time after the first 
start time when the URL was first invoked through a hyperlink as part of a remote 
director instruction for control of streaming digital content, the macros being 
stored in the order in which the URLs are first invoked through hyperlinks; 

means, recorded upon the recording medium, for establishing a second start time 
for retransmitting the event; 

means, recorded upon the recording medium, for reading from computer memory 
the macros in the order in which the macros were stored; 

means, recorded upon the recording medium, for invoking each URL of each 
macro as a hyperlink at a second elapsed time after the second start time, the 
second elapsed time being approximately equal to the first elapsed time of the 
macro, means for invoking each URL further comprising means for issuing a 
remote director instruction; 

means, recorded upon the recording medium, for retrieving from the non- volatile, 
machine-readable storage, means for transcoding, means for selecting for 
inclusion in output streams, and means for communicating to client devices, in 
dependence upon remote director instructions, the digital content. 

The computer program product of claim 25 further comprising: 

means, recorded upon the recording medium, for registering a user for a 
retransmission of an event, the retransmission of an event identified by an event 
identification code, the retransmission of an event comprising at least one video 
stream, at least one source, a start date and a start time; 
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means, recorded upon the recording medium, for logging in a user for the 
retransmission of an event, means for logging in a user further comprising means 
for assigning values to user login attributes, the user login attributes comprising 
user identification, device type, network address, and a tier; 

means, recorded upon the recording medium, for assigning a tier value in 
dependence upon the device type and the event identification code; 

wherein the selections are dependent upon the tier; 

wherein means for transcoding further comprises means for transcoding in 
dependence upon the tier; and 

wherein means for communicating to at least one of the client devices the output 
video stream further comprises means for communicating the output video stream 
to the network address. 

The computer program product of claim 26 wherein: 

means for registering a user further comprises means for creating an event 
registration record comprising event registration attributes including comprising 
user identification, event identification, event subscription level, start date, and 
start time; and 

means for assigning a tier value further comprises means for assigning a tier value 
in dependence upon the event subscription level. 
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Abstract. This paper presents Open Java, which is a macro system that 
we have developed for Java. With traditional macro systems designed for 
non object-oriented languages, it is difficult to write a number of macros 
typical in object-oriented programming since they require the ability to 
access a logical structure of programs. One of the drawbacks of tradi- 
tional macro systems is that abstract syntax trees are used for repre- 
senting source programs. This paper first points out this problem and 
then shows how OpenJava addresses this problem. A key idea of Open- 
Java is to use metaobjects, which was originally developed for reflective 
computing, for representing source programs. 

1 Introduction 

Reflection is a technique for changing the program behavior according to another 
program. Prom software engineering viewpoint, reflection is a tool for separation 
of concerns and thus it can be used for letting programmers write a program 
with higher-level abstraction and with good modularity. For example, a number 
of reflective systems provide metaobjects for intercepting object behavior, that 
is, method invocations and field accesses. Those metaobjects can be used for 
weaving several programs seprately written from distinct aspects, such as an 
application algorihtm, distribution, resource allocation, and user interface, into 
a single executable program. 

However, previous reflective systems do not satisfy all the requirements in 
software engineering. Although the abstraction provided by the metaobjects for 
intercepting object behavior is easy to understand and use, they can be used for 
implementing only limited kinds of separation of concerns. Moreover, this type 
of reflection often involves runtime penalties. Reflective systems should enable 
more fine-grained program weaving and perform as much reflective computation 
as possible at compile time for avoiding runtime penalities. 

On the other hand, a typical tool for manipulating a program at compile time 
has been a macro system. It performs textual substitution so that a particualr 
aspect of a program is separated from the rest of that program. For example, 
the C/C++ macro system allows to separate the definition of a constant value 



from the rest of a program, in which that constant value is used in a number 
of distinct lines. The Lisp macro system provides programable macros, which 
enables more powerful program manipulation than the C/C++ one. Also, since 
macro expansion is done at compile time, the use of macros does not imply any 
runtime penalties. However, the abstraction provided by traditional macro sys- 
tems is not sophisticated; since macros can deal with only textual representation 
of a program, program manipulation depending on the semantic contexts of the 
program cannot be implemented with macros. 

This paper proposes a macro system integrating good features of the reflective 
approach, in other words, a compile-time reflective system for not only behav- 
ioral reflection but also structural reflection. A key idea of our macro system, 
called OpenJava, is that macros (meta programs) deal with class metaobjects 
representing logical entities of a program instead of a sequence of tokens or ab- 
stract syntax trees (ASTs). Since the class metaobjects abstract both textual 
and semantic aspects of a program, macros in OpenJava can implement more 
fine-grained program weaving than in previous reflective systems. They can also 
access semantic contexts if they are needed for macro expansion. This paper 
presents that OpenJava can be used to implement macros for helping complex 
programmings with a few design patterns. 

In the rest of this paper, section 2 presents a problem of ordinary macro sys- 
tems and section 3 discusses the design and implementation of OpenJava, which 
addresses this problem. We compare OpenJava with related work in section 4. 
Finally, section 5 concludes this paper. 



2 Problems with Ordinary Macros 

Macro systems have been typical language-extension mechanisms. With C/C++ 's 
#def ine macro system, programmers can specify a symbol or a function call to 
be replaced with another expression, although this replacement is simple token- 
based substitution. In Common Lisp, programmers can write more powerful 
macros. However, even such powerful macros do not cover all requirements of 
00 languages programming. 



2.1 Programmable Macros 

Macros in Common Lisp are programmable macros. They specify how to replace 
an original expression in Common Lisp itself. A macro function receives an 
AST (abstract syntax tree) and substitutes it for the original expression. Since 
this macro system is powerful, the object system of Common Lisp (CLOS) is 
implemented with this macro system. 

Programmable macros have been developed for languages with more complex 
syntax like C. MS 2 [19] is one of those macro systems for C. Macro functions are 
written in an extended C language providing special data structure representing 
ASTs. The users of MS 2 can define a new syntax and how it is expanded into 



a regular C syntax. The parameter that a macro function receives is an AST of 
the code processed by that macro function. 

One of the essential issue in designing a programmable macro system is a 
data structure representing an original source program. Another essential issue 
is now to specify where to apply each macro in a source program. For the former 
most systems employed ASTs. For the latter, several mechanisms were proposed' 
In Common Lisp and MS 2 , a macro is applied to expressions or statements 
beginning with the trigger word specified by the macro. For example, if the 
trigger word is unless, all expressions beginning with unless are expanded by 
that macro. In this way, they cannot use macros without the trigger words For 
instance, it is impossible to selectively apply a macro to only + expressions for 
adding string objects. 

Some macro systems provide fine-grained control of where to apply a macro. 
In A* [14], a macro is applied to expressions or statements matching a pattern 
specified in the BNF. In EPP[9], macros are applied to a specified syntax ele- 
ments like if statements or + expressions. There's no need to put any trigger 
word in front of these statements or expressions. 



2.2 Representation of Object-Oriented Programs 

Although most of macro systems have been using ASTs for representing a source 
program, ASTs are not the best representation for all macros: some macros typ- 
ical in 00 programming require a different kind of representation. ASTs are 
purely textual representation and independent of logical or contextual informa- 
tion of the program. For example, if an AST represents a binary expression, the 
AST tells us what the operator and the operands are but it never tells us the 
types of the operands. Therefore, writing a macro is not possible with ASTs 
if the macro expansion depends on logical and contextual information of that 
binary expression. 

There is a great demand for the macros depending on logical and contextual 
information in 00 programming. For example, some of design patterns[6j re- 
quire relatively complicated programming. They often require programmers to 
repeatedly write similar code.[l] To help this programming, several researchers 
have proposed to extend a language to provide new language constructs special- 
ized for particular patterns [1, 7], Those constructs should be implemented with 
macros although they have been implemented so far by a custom preprocessor. 
This is because macros implementing those constructs depend on the logical and 
contextual information of programs and thus they are not implementable on top 
of the traditional AST-based macro systems. 

Suppose that we write a macro for helping programming with the Ob- 
server^] pattern, which is for describing one-to-many dependency among ob- 
jects. This pattern is found in the Java standard library although it is called 
the event-and-listener model. For example, a Java program displays a menu bar 
must define a listener object notified of menu-select events. The listener object 
is an instance of a class My Menu Listener implementing interface MenuListener: 



class MyMenuListener implements MenuListener { 
void menuSelected(MenuEvent e) { . . } 
void menuDeselected(MenuEvent e) { return; } 
void menuCanceled(MenuEvent e) { return; } 

This class must declare all the methods for event handling even though some 
events, such as the menu cancel event, are simply ignored. 

We write a macro for automating declaration of methods for handling ignored 
events. If this macro is used, the definition of MyMenuListener should be re- 
written into: 

class MyMenuListener follows ObserverPattern 
implements MenuListener 

{ 

void menuSelected(MenuEvent e) { . . } 

} 

The follows clauses specifies that our macro ObserverPattern is applied to this 
class definition. The declarations of menuDeselectedO and aenuCanceledQ are 
automated. This macro first inspects which methods declared in the interface 
MenuListener are not implemented in the class MyMenuListener. Then it inserts 
the declarations of these methods in the class MyMenuListener. 

Writing this macro is difficult with traditional AST-based macro systems 
since it depends on the logical information of the definition of the class My- 
MenuListener. If a class definition is given as a large AST, the macro program 
must interpret the AST and recognize methods declared in MenuListener and 
MyMenuListener. The macro program must also construct ASTs representing 
the inserted methods and modify the original large AST to include these ASTs. 
Manipulating a large AST is another difficult task. To reduce these difficulties, 
macro systems should provide logical and contextual information of programs 
for macro programs. There are only a few macro systems providing the logical 
information. For example, XL[15] is one of those systems although it is for a 
functional language but not for an 00 language. 

3 OpenJava 

Open Java is our advanced macro system for Java. In OpenJava, macro programs 
can access the data structures representing a logical structure of the programs. 
We call these data structure class metaobjects. This section presents the design 
of OpenJava. 

3.1 Macro Programming in OpenJava 

OpenJava produces an object representing a logical structure of class definition 
for each class in the source code. This object is called a class metaobject. A class 



metaobject also manages macro expansion related to the class it represents Pro- 
grammers customize the definition of the class metaob jects for describing macro 
expansion. We call the class for the class metaobject .metadata. In OpenJava 
the rnetaprogram of a macro is described as a metaclass. Macro expansion by 
OpenJava is divided into two: the first one is macro expansion of class decla- 
rations (caUee-side), and the second one is that of expressions accessing classes 
(caller-side). 

Applying Macros Fig. 1 shows a sample using a macro in OpenJava By 
adding a clause instantiates M in just after the class name in a class declara- 
tion, the programmer can specify that the class metaobject for the class is an 
instance of the metaclass M. In this sample program, the class metaobject for 
My Menu Listener is an instance of ObserverClass. This metaobject controls macro 
expansion mvolved with MyMenuListener. The declaration of ObserverClass is 
described in regular Java as shown in Fig. 2. 

class MyMenuListener 

instantiates ObserverClass 
extends MyObject 
implements MenuListener 

i .... > 

Fig. X. Application of a macro in OpenJava 



class ObserverClass 
extends OJClass 

{ 

void translateDef initionO < . . . > 



Fig. 2. A macro in OpenJava 



Every metaclass must inherit from the metaclass OJClass, which is a built-in 
class of OpenJava. The translateDef initionO in Fig. 2 is a method inherited 
from OJClass, which is invoked by the system to make macro expansion. If an 
instantiates clause in a class declaration is found, OpenJava creates an in- 
stance of the metaclass indicated by that instantiates clause, and assigns this 
instance to the class metaobject representing that declared class. Then Open- 
Java invokes translateDef initionO on the created class metaobject for macro 
expansion on the class declaration later. 



Since the translateDef initionO declared in OJCiass does not perform 
any translation, a subclass of OJCiass must override this method for the desired 
macro expansion. For example, translateDef initionO can add new member 
methods to the class by calling other member methods in OJCiass. Modifications 
are reflected on the source program at the final stage of the macro processing. 

Describing a Metaprogram The method translateDef initionO imple- 
menting the macro for the Observer pattern in section 2.2 is shown in Fig. 3. 
This metaprogram first obtains all the member methods (including inherited 
ones) defined in the class by invoking getMethodsO on the class metaobject. 
Then, if a member method declared in interfaces is not implemented in the class, 
it generates a new member method doing nothing and adds it to the class by 
invoking addMethodQ on the class metaobject. 

void translateDef initionO { 

OJKetfeodO a - this, getttethods (this) ; 
for Cint i - 0; i < m. length; { 

OJHodifier tnodif - nti] .getModif iersO; 
if Caodif .ioAbotractO) { 

OJMethod n - new OJMethod (this, 

n[i] .getModif iersO .removeAbstractO , 
o[i] .gotRaturnTypeO , o[i] .got Name () , 
m[i] .getParaaetexTypesO , 
n[i] .getEzceptianTypesO » 
makeStatenentList ("return; ") ) ; 
tnis.addMetnodCn); 

> 

> 

> 



Fig. 3. translateDef initionO in ObserverClass 

As a class is represented by a class metaobjects, a member method is also 
represented by a method metaobjects. In OpenJava, classes, member methods, 
member fields, and constructors are represented by instances of the class OJCiass, 
OJMethod, OJField, and 0 J Constructor, respectively. These metaobject represent 
logical structures of class and member definitions. They are easy to handle, 
compared to directly handling large ASTs representing class declarations and 
collecting information scattered in these ASTs. 

3.2 Class Metaobjects 

As shown in section 2, a problem of ordinary macro systems is that their pri- 
mary data structure is ASTs (abstract syntax trees) but they are far from logical 
sturctures of programs in 00 languages. In 00 languages like Java, class def- 
initions play an important role as a logical structure of programs. Therefore, 
OpenJava employs the class metaobjects model, which was originally developed 
for reflective computing, for representing a logical structure of a program. The 



class metaobjects make it easy for meta programs to access a logical structure 
of program. 

Hiding Syntactical Information In Java, programmers can use various syn- 
tax for describing the logically same thing. These syntactical differences are 
absorbed by the metaobjects. For instance, there are two notations for declaring 
a String array member field: 

String □ a; 
String b[]; 

Both a and b are String array fields. It would be awkward to write a metapro- 
gram if the syntactical differences of the two member fields had to be considerd. 
Thus 0 J Field provides only two member methods getTypeO and setTypeO 
for handling the type of a member field. getTypeO on the OJField metaobjects 
representing a and b returns a class metaobject representing the array type of 
the class String. 

Additionally, some elements in the grammer represent the same element in 
a logical structure of the language. If one of these element is edited, the others 
are also edited. For instance, the member method setNameQ in 0 J Class for 
modifying the name of the class changes not only the class name after the class 
keyword in the class declaration but also changes the name of the constructors. 

Logically Structured Class Representation Simple ASTs, even arranged 
and abstracted well, cannot properly represent a logical structure of a class 
definition. The data structure must be carefully designed to corresponded not 
only to the grammer of the language but also to the logical constructs of the 
language like classes and member methods. Especially, it makes it easy to handle 
the logical information of program including association between names and 
types. 

For instance, the member method getMethodsQ in 0 J Class returns all the 
member methods defined in the class which are not only the methods immedi- 
ately declared in the class but also the inherited methods. The class metaobjects 
contain type information so that the definition of the super class can be acces- 
sible. 

3.3 Class Metaobjects in Details 

The root class for class metaobjects is 0 J Class. The member methods of 0 J Class 
for obtaining information about a class are shown in Tab. 1 and Tab. 2. They 
cover all the attributes of the class. In OpenJava, all the types, including array 
types and primitive types like int, have corresponding class metaobjects. Using 
the member methods shown in Tab. 1, metaprogramms can inspect whether a 
given type is an ordinary class or not. 

Tab. 3 gives methods for modifying the definition of the class. Metaprograms 
can override translateDef initionO in 0 J Class so that it calls these methods 



for executing desired modifications. For instance, the example shown in Pig. 3 
adds newly generated member methods to the class with addMethodO . 



Table 1. Member Methods in OJCIass for Non-Class Types 



boolean ielntarfaceO 

Tests if this represents an interface type, 
boolean isArrayC) 

Tests if this represents an array type. 

boolean iaPrimitiveO 

Tests if this represents an premitive type. 

OJCIass getConponantTypeO 

Returns a class xnetaobject for the type of array components. 



Metaobjects Obtained through Class Metaobjects The method getSuperclassQ 
in OJCIass, which is used to obtain the superclass of the class, returns a class 
metaobject instead of the class name (as a string). As the result, metaprogram 
can use the returned class metaobject to directly obtain information about the 
superclass. OpenJava automatically generates class metaobjects on demand, 
even for classes declared in another source file or for classes available only in 
the form of bytecode, that is, classes whose source code is not available. 

The returned value of the member method getModif iersQ in Tab. 2 is an 
instance of the class 0 J Modifier. This class represents a set of class modifiers 
such as public, abstract or final. Metaprogramms do not have to care about 
the order of class modifiers because 0 J Modifier hides such useless information. 

The class 0 J Method, which is the return type of getDeclaredMetbodsO 
in OJCIass, represents a logical structure of a method. Thus, similarly to the 
class OJCIass, this class has member methods for examining or modifying the 
attributes of the method. Some basic member methods in 0 J Method are shown in 
Tab. 4. Any type information obtained from these methods is also represented by 
a class metaobject. For instance, getRetuxnTypeO returns a class metaobject 
as the return type of the method. This feature of 0 J Method is also found in 
OJField and 0 J Constructor, which respectively represent a member field and a 
constructor. 

The class StatementList, which is the return type of the member method 
getBodyO in the class OJMethod, represents the statements in a method body. 
An instance of StatementList consists of objects representing either expressions 
or statements. StatementList objects are AST- like data structures although they 
contain type information. This is because we thought that the logical structure 
of statements and expressions in Java can be well represented with ASTs. 



Table 2. Member Methods in OJCIass for introspection (1) 



String getPackageHameO 

Returns the package name this class belongs to. 
String getSiapletfemeO 

Returns the unqualified name of this class. 
OJModifior getKodifiersO 

Returns the modifiers for this class. 
OJCIass getSupor class () 

Returns the superclass declared explicitly or implicitly. 
OJCIass □ getDeclaredXnterfacesO 

Returns all the declared superinterfaces. 

StatemeatList gotlnitializerO 

Returns all the static initializer statements. 
OJFieldO getDeelaredFieldsO 

Returns all the declared fields. 

OJMethodD getDeclaxedttethodsO 

Returns all the declared methods. 
OJComctructorD getD»claredCcnstructors() 

Returns all the constructors declared explicitly or implicitly. 

OJCIass Q gatDeclaredClassesO 

Returns all the member classes (inner classes). 

OJCIass getDedaringClassO 

Returns the class declaring this class (outer class). 



Table 3. Member Methods in OJCIass for modifying the class 



String setSimplenaae (String nana) 

Sets the unqualified name of this class. 

OJModifior setHodifiers(OJHodifier raodifs) 

Sets the class modifiers. 
OJCIass setSuperclass (OJCIass clazz) 

Sets the superclass. 

DJClass □ set Interfaces (OJCIass Q faces) 
Sets the superinterfaces to be declared. 

OJField rmoveFieldCOJFiald field) 

Removes the given field from this class declaration. 

OJKothod rwoveHethod(OJHethod method) 

Removes the given method from this class declaration. 

OJConotructor retooveConstrnctorCOJConstructor constr) 

Removes the given constructor from this class declaration. 

OJField addFi«ld(0J7ield field) 

Adds the given field to this class declaration. 

OJKetfcod addHethod(DJHetfcod method) 

Adds the given method to this class declaration. 

OJConstructor addConatructor (OJConstructor constr) 

Adds the given constructor to this class declaration. 



Table 4. Basic Methods in OJMethod 



String getHameO 

Returns the name of this method. 
OJModifier getHodixiarsO 

Returns the modifiers for this method. 
OJClass getRetiirnTypeO 

Returns the return type. 

OJClass □ getParaxftotorTypoa 0 

Returns the parameter types in declaration order. 

OJClass □ getErceptionTypesO 

Returns the types of the exceptions declared to be thrown. 

String □ getParaaeterVariablesO 

Returns the parameter variable names in declaration order. 
StatementList got Body C) 

Returns the statements of the method body. 
String setNaae (String name) 

Sets the name of this method. 

OJModifiar setHodif iersCOJModifier nodifs) 

Sets the method modifiers. 
OJClass setRetnrnTypaO 

Sets the return type. 

OJClass □ bo t Parameter Types O 

Sets the parameter types in declaration order. 

OJClass □ set Except ionType s () 

Sets the types of the exceptions declared to be thrown. 

String f] setParaaet er Variables O 

Sets the parameter variable names in declaration order. 

StatementList set Body () 

Sets the statements of the method body. 



Logical Structure of a Class Tab. 5 shows the member methods in OJCIass 
handling a logical structure of a class. Using these methods, metaprograms can 
obtain information considering class inheritance and member hiding. Although 
these member methods can be implemented by combining the member methods 
in Tab.2, they are provided for convenience. We think that providing these meth- 
ods is significant from the viewpoint that class metaobjects represent a logical 
structure of a program. 

Table 5. Member Methods in OJCIass for introspection (2) 



OJCIass □ gatlnterfacesO 

Returns all the interfaces implemented by this class or the all the super- 
interfaces of this interface. 

boolean iaAssignableFromCOJClass clazz) 

Determines if this class/interface is either the same as, or is a superclass 
or superinterface of, the given class/ interface. 

OJHethodQ getMathods (OJCIass situation) 

Returns all the class available from the given situation, including those 
declared and those inherited from superclasses/super interfaces. 

DJMetnod getHethod (String name, OJCIass □ types, OJCIaeo situation) 
Returns the specified method available from the given situation. 

DJMethod getlnvokodMethod (String name, OJCIass □ types, OJCIass situation) 
Returns the method, of the given name, invoked by the given arguments 
types, and available from the given situation. 



In considering the class inheritance mechanism, the member methods de- 
fined in a given class are not only the member methods described in that class 
declaration but also the inherited ones. Thus, method metaobjects obtained by 
invoking getMethods () on a class metaobject include the methods explicitly de- 
clared in its class declaration but also the methods inherited from its superclass 
or superinterfaces. 

Moreover, accessibility of class members is restricted in Java by member 
modifiers like public, protected or private. Thus, getMethods () returns 
only the member methods available from the class specified by the argument. 
For instance, if the specified class is not a subclass or in the same package, 
getMethods () returns only the member methods with public modifier. In Fig. 3, 
since the metaprogram passes this to getMethods () , it obtains all the member 
methods defined in that class. 



3.4 Type-Driven Translation 

As macro expansion in OpenJava is managed by metaobjects corressponding to 
each class (type), this translation is said to be type-driven. In the above example, 
only the member method translateDef initionO of OJCIass is overridden to 
translate the class declarations of specified classes (callee-side translation). 



In addition to the callee-side translation, OJClass provides a framework to 
translate the code related to the corresponding class spreaded over whole pro- 
gram selectively (caller-side translation). The parts related to a certain class is, 
for example, instance creation expressions or field access expressions. 

Here, we take up an example of a macro that enables programming with 
the Flyweight[6] pattern to explain this mechanism. This design pattern is 
applied to use objects-sharing to support large numbers of fine-grained objects 
efficiently. An example of macro supporting uses of this pattern would need to 
translate an instance creation expression of a class Glyph: 

new Glyph('c') 

into a class method call expression: 

GlyphFactory . createCharacter ( ' c ' ) 

The class method createCharacter () returns an object of Glyph correspon- 
dent to the given argument if it was already generated, otherwise it creates a new 
object to return. This way, the program using Glyph objects automatically shares 
an object of Glyph representing a font for a letter c without generating several ob- 
jects for the same letter. In ordinary programming using Glyph objects with the 
Flyweight pattern, programmers must explicitly write createCharacter () in 
their program with creations of Glyph objects. With a support of this macro, 
instance creations can be written in the regular new syntax and the pattern is 
used automatically. 

In Open Java, this kind of macro expansions are implemented by defining a 
metaclass FlyweightClass to be applied to the class Glyph. This metaclass over- 
rides the member method expandAllocationO of OJClass as in Fig.4. This 
method receives a class instance creation expression and returns a translated 
expression. The system of Open Java examines the whole source code and apply 
this member method to each Glyph instance creation expression to perform the 
macro expansion. 

Expression expaiuiAlloc&t ion (Alio cat ionErpr ess ion expr, Environment anv) { 
Express ionList ergs * expr. get Argument s(); 
return new MethodCall (this , "createCharacter'' r args); 

> 

Fig. 4. Replacement of class instance expressions 

The member method expandAllocationO receives an AllocationExpression 
object representing a class instance creation expression and an Environment ob- 
ject representing the enviroment of this expression. The Environment object holds 
name binding information such as type of variable in the scope of this expression. 

OpenJava uses type-driven translation to enable the complehensive macro 
expansion of partial code spreaded over various places in program. In macro 
systems for 00 programing languages, it is not only needed to translate a class 



declaration simply but translating expressions using the class togather is also 
needed. In OpenJava, by defining a methods like expandAllocationO , metapro- 
grammers can selectively apply macro expansion to the limited expressions re- 
lated to classes controlled by the metaclass. This kind of mechanism has not been 
seen in most of ordinary macro systems except some systems like OpenC++f3] 
Tab. 6 shows the primary member methods of OJCIass which can be overridden 
for macro expansion at caller-side. 

Table 6. Member Methods for Each Place Applied the Macro-Expansion to 



Member method 



translateDef iaitie&O 
axpandlllocationO 
expandArrayAHocatian O 
expandTypeNaae ( ) 
«xpaztdMethodCaU () 
expandFieldReadO 
expandFieldHriteO 
oxpondCaatedExpressionO 
oipandCast Expression ( ) 



Place applied the macro expansion to" 
Class declaration 

Class instance allocation expression 
Array allocation expression 
Class name 

Method class expression 
Field-read expression 
Field-write expression 
Casted expression from this type 
Casted expression to this type 



3.5 Translation Mechanism 

Given a source program, the processor of OpenJava: 

1. Analyzes the source program to generate a class metaobject for each 
class. 

2. Invokes the member methods of class metaobjects to perform macro 
expansion. 

3. Generates the regular Java source program reflecting the modifica- 
tion made by the class metaobjects. 

4. Executes the regular Java compiler to generate the corresponding 
byte code. 

The Order of Translations Those methods of OJCIass whose name start from 
expand performs caller-side translation, and they affect expressions in source 
program declaring another class C. Such expressions may also be translated by 
translateDef initionO of the class metaobject of C as callee-side translation. 
Thus different class metaobjects affect the same part of source program. 

In OpenJava, to resolve this ambiguousness of several macro expansion, 
the system always invokes translateDef initionO first as callee-side transla- 
tion, then it apply caller-side translation to source code of class declarations 
which was already applied callee-side translation. Metaprogrammers can de- 
sign metaprogram considering this specified order of translation. In this rule, 



if translateDef initionO changes an instance creation expression of class X 
into Y's, expandAllocationO defined in the metaclass of X is not performed. 

Moreover, the OpenJava system always performs translateDef initionO 
for superclasses first, i.e. the system performs it for subclasses after superclasses 
As a class definition strongly depends on the definition of its superclass, the 
translation of a class often varies depending on the definition of its superclass. 
To settle the definition of superclasses, the system first translates the source 
program declaring superclasses. Additionally, there are some cases where the 
definition of a class D affects the result of translation of a class E. In Open- 
Java, from translateDef initionO for E, metaprogrammer can explicitly spec- 
ify that translateDef initionO for D must be performed before. 

In the case there are dependency relationships of translation among several 
macro expansions, consistent order of translation is specified to address this 
ambiguousness of translation results. 



Dealing with Separate Compilation In Java, classes can be used in program 
only if they exist as source code or byte code (.class file). If there is no source 
code for a class C, the system cannot specify the metaclass of C, as is. Then, for 
instance, it cannot perform the appropriate expandAllocationO on instance 
creation expressions of C. 

Therefore, OpenJava automatically preserves metalevel information such as 
the metaclass name for a class when it processes the callee-side translation of each 
class. These preservation are implemented by translating these information into a 
string held in a field of a special class, which is to be compiled into byte code. The 
system uses this byte code to obtain necessary metalevel information in another 
process without source code of that class. Additionally, metaprogrammers can 
request the system to preserve customized metalevel information of a class. 

Metalevel information can be preserved as special attributes of byte code. 
In OpenJava, such information is used only at compile-time but not at runtime. 
Thus, in order to save runtime overhead, we choosed to preserve such information 
in separated byte code which is not to be loaded by JVM at runtime. 



3.6 Syntax Extension 

With OpenJava macros, a metaclass can introduce new class/member modifiers 
and clauses starting with the special word at some limited positions of the regular 
Java grammar. The newly introduced clauses are valid only in the parts related 
to instances of the metaclass. 

In a class declaration (callee-side), the positions allowed to introduce new 
clauses are: 

- before the block of member declarations, 

- before the block of method body in each method declaration, 

- after the field variable in each field declaration. 

And in other class declarations (caller-side), the allowed position is: 



— after the name of the class. 



Thanks to the limited positions of new clauses, the system can parse source 
programs without conflicts of extended grammers. Thus, metaprogrammers do 
not have to care about conflicts between clauses. 

class VectorStack instantiates AdapterCIass 
adapts Vector in v to Stack 

{ 
> 

Fig. 5. An example of syntax extension in OpenJava 

Fig. 5 shows an example source program using a macro, a metaclass Adapter- 
Class, supporting programming with the Adapter pattern[6]. The metaclass in- 
troduces a special clause beginning with adapts to make programmers to write 
special description for the Adapter pattern in the class declaration. The adapts 
clause in the Pig. reffig: VectorStack VectorStack is the adapter to a class Stack 
for a class Vector. The information by this clause is used only when the class 
metaobjects representing VectorStack performs macro expansion. Thus, for other 
class metaobjects, semantical information added by the new clause is recognized 
as a regular Java source code. 

static SyntaxRule getDeclSutfix (String keyword) { 
if (keyword. equals ("adapts p )) { 
return new CoopoBiteRaleC 
new TypeH&meRxile () , 

new PrepPhraseftule ( " in" , new IdentifierRnleO), 
new PrepPhraseRuleCto", new TypeHameKule (> ) ); 

> 

return null; 

> 

Fig. 6. A meta-program for a customized suffix 

To introduce this adapts clause, metaprogrammers implement a member 
method getDeclSuf f ix() in the metaclass AdapterCIass as shown in Fig. 6. 
The member method getDeclSuf fix () is invoked by the system when needed, 
and returns a SyntaxRule object representing the syntax grammer begenning 
with the given special word. An instance of the class SyntaxRule implements 
a recursive descendant parser of LL(k), and analyzes a given token series to 
generate an appropriate AST. The system uses SyntaxRule objects obtained by 
invoking getDeclSuf fix() to complete the parsing. 

For metaprogrammers of such SyntaxRule objects, OpenJava provides a class 
library of subclasses of SyntaxRule, such as parsers of regular Java syntax ele- 
ments and synthesizing parser for tying, repeating or selecting other SyntaxRule 



objects. Metaprogrammers can define their desired clauses by using this 
or by implementing a new subclass of SyntaxRule. 



3.7 Metaclass Model of OpenJava 

A class must be managed by a single metaclass in OpenJava. Though it would 
be useful if programmers could apply several metaclasses to a class, we did not 
implement such a feature because there is a problem of conflict of translation 
between metaclasses. And, a metaclass for a class A does not manage a subclass 
A' of A, that is, the metaclass of A does not perform the callee-side and caller- 
side translation of A' it is not specified to be the metaclass of A' in the source 
program declaring A'. 

For innerclasses such as member classes, local classes, anonymous classes in 
the Java language, each of them are also an instance of a metaclass in OpenJava. 
Thus programmers may apply a desired metaclass to such classes. 



4 Related Work 

There are a number of systems using the class metaob jects model for represent- 
ing a logical structure of a program: 3-KRS[16], 0bjVlisp[5], CLOS MOP[13], 
Smalltalk-80[8], and so on. The reflection API[11] of the Java language also uses 
this model although the reflection API does not allow to change class metaob- 
jects; it only allows to inspect them. Furthermore, the reflection API uses class 
metaob jects for making class definition accessible at runtime. On the other hand, 
OpenJava uses class metaobjects for macro expansion at compile-time. 

OpenC-H-[3] also uses the class metaobject model. OpenJava inherits sev- 
eral features, such as the type-driven translation mechanism, from OpenC+-k 
However, the data structure mainly used in OpenC-hf is still an AST (abstract 
syntax tree). MPC++[10] and EPP[9] are similar to OpenC++ with respect to 
the data structure. As mentioned in section 2, an AST is not an appropriate 
abstraction for some macros frequently used in 00 progreunming. 



5 Conclusion 

This paper describes OpenJava, which is a macro system for Java providing 
a data structure called class metaobjects. A number of research activities have 
been done for enhancing expressive power of macro systems. This research is also 
in this stream. OpenJava is a macro system with a data structure representing 
a logical structure of an 00 program. This made it easier to describe typical 
macros for 00 prograniming which was difficult to describe with ordinary macro 
systems. 

To show the effectiveness of OpenJava, we implemented some macros in 
OpenJava for supporting programming with design patterns. Although we saw 
that class metaobjects are useful for describing those macros, we also found 



limitations of OpenJava. Since a single design pattern usually contains several 
classes, a macro system should be able to deal with those classes as a single 
entity[17]. However it is not easy for OpenJava to do that because macros are 
applied to each class. It is future work to address this problem by incorporate 
OpenJava with techniques like aspect-oriented programming[12]. 
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Preface 



The Java™ Media Framework (JMF) is an application programming inter- 
face (API) for incorporating time-based media into Java applications and 
applets. This guide is intended for Java programmers who want to incor- 
porate time-based media into their applications and for technology pro- 
viders who are interested in extending JMF and providing JMF plug-ins to 
support additional media types and perform custom processing and ren- 
dering. 



About JMF 

The JMF 1.0 API (the Java Media Player API) enabled programmers to 
develop Java programs that presented time-based media. The JMF 2.0 API 
extends the framework to provide support for capturing and storing 
media data, controlling the type of processing that is performed during 
playback, and performing custom processing on media data streams. In 
addition, JMF 2.0 defines a plug-in API that enables advanced developers 
and technology providers to more easily customize and extend JMF func- 
tionality 

The following classes and interfaces are new in JMF 2.0: 

Audi oFormat Bi tRateCont rol 



BufferControl 

CaptureDevi ce 

CI oneabl eDataSou rce 

ConnnectionErrorEvent 



BufferToImage 
Captu reDevi ceinf o 
Codec 
DataSink 



Buffer 
BufferTransferHandler 
Captu reDevi ceManager 
Conf i gureCompl eteEvent 
DataSinlcErrorEvent 



DataSinkEvent 



DataSinkListener 



Demultiplexer 
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Effect 


EndOfStreamEvent 


Fi 1 eTypeDescri ptor 


Format 


FormatChangeEvent 


FormatControl 


FrameCrabbi ngControl 


FramePositioni ngControl 


FrameProcessi ngControl 


FrameRateControl 


H261Control 


H261Format 


H263Control 


H263Format 


ImageToBuffer 


IndexedCol orFormat 


InputSourceStream 


KeyFrameControl 


MonitorControl 


MpegAudioControl 


Multipl exer 


NoStorageSpaceErrorEvent 


PacketSizeControl 


Plugln 


PluglnManager 


PortControl 


Processor 


Processor-Model 


Pul 1 Buff erDataSou rce 


Pull Buff erStream 


PushBuff erDataSou rce 


Pu s hBuffe rSt ream 


QualityControl 


(tenderer 


RCBFormat 


SilenceSuppressionControl 


St r eamWr i te rCon t rol 


Track 


TrackControl 


VideoFormat 


VideoRenderer 


YUVFormat 



In addition, the Medi aPl ayer Java Bean has been included with the JMF 
API in j avax . medi a . bean . pi aye rbean. Medi aPl aye r can be instantiated 
directly and used to present one or more media streams. 

Future versions of the JMF API will provide additional functionality and 
enhancements while maintaining compatibility with the current APL 



Design Goals for the JMF API 

JMF 2.0 supports media capture and addresses the needs of application 
developers who want additional control over media processing and ren- 
dering. It also provides a plug-in architecture that provides direct access 
to media data and enables JMF to be more easily customized and 
extended. JMF 2.0 is designed to: 

• Be easy to program 

• Support capturing media data 

• Enable the development of media streaming and conferencing 
applications in Java 



• Enable advanced developers and technology providers to implement 
custom solutions based on the existing API and easily integrate new 
features with the existing framework 

• Provide access to raw media data 

• Enable the development of custom, downloadable demultiplexers, 
codecs, effects processors, multiplexers, and Tenderers (JMF plug-ins) 

• Maintain compatibility with JMF 1.0 



About the JMF RTP APIs 

The classes in javax. media, rtp, javax. media, rtp. event, and 
javax. media, rtp. rtcp provide support for RTP (Real-Time Transport Pro- 
tocol). RTP enables the transmission and reception of real-time media 
streams across the network. RTP can be used for media-on-demand appli- 
cations as well as interactive services such as Internet telephony. 

JMF-compliant implementations are not required to support the RTP 
APIs in javax. media. rtp, javax. media. rtp. event, and 
javax. media. rtp. rtcp. The reference implementations of JMF provided 
by Sun Microsystems, Inc. and IBM Corporation fully support these APIs. 

The first version of the JMF RTP APIs (referred to as the RTP Session Man- 
ager API) enabled developers to receive RTP streams and play them using 
JMF. In JMF 2.0, the RTP APIs also support the transmission of RTP 
streams. 

The following RTP classes and interfaces are new in JMF 2.0: 

SendStream SendStreamLi stener Inacti veSendSt reamEvent 

ActiveSendStreamEvent SendPayl oadChangeEvent NewSendStreamEvent 

GlobalTransmi ssionStats Transmissi onStats 

The RTP packages have been reorganized and some classes, interfaces, 
and methods have been renamed to make the API easier to use. The pack- 
age reorganization consists of the following changes: 

• The RTP event classes that were in javax. media, rtp. session are now 
in j avax . medi a . rtp . event. 

• The RTCP-related classes that were in j avax . medi a . rtp . sessi on are 
now in javax . medi a . rtp . rtcp. 
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• The rest of the classes in j avax . medi a . rtp . sessi on are now in 
javax. media, rtp and the javax. media, rtp. session package has been 
removed. 



The name changes consist primarily of the removal of the RTP and RTCP 
prefixes from class and interface names and die elimination of non-stan- 
dard abbreviations. For example, RTPRecvStreamListener has been 
renamed to ReceiveStreamListener. For a complete list of the changes 
made to the RTP packages, see the JMF 2.0 Beta release notes. 

In addition, changes were made to the RTP APIs to make them compatible 
with other changes in JMF 2.0: 

• javax. media. rtp. session, io and 

javax. medi a. rtp. session . depacketizer have been removed. Custom 
RTP packetizers and depacketizers are now supported through the 
JMF 2.0 plug-in architecture. Existing depacketizers will need to be 
ported to the new plug-in architecture. 

• Buffer is now the basic unit of transfer between the SessionManager 
and other JMF objects, in place of DePacketi zedUni t and 
DePacketizedObject. RTP-formatted Buffers have a specific format 
for their data and header objects. 

• BaseEncodi nglnfo has been replaced by the generic JMF Format object. 
An RTP-specific Format is differentiated from other formats by its 
encoding string. Encoding strings for RTP-specific Formats end in 
_RTP. Dynamic payload information can be provided by associating a 
dynamic payload number with a Format object. 

Design Goals for the JMF RTP APIs 

The RTP APIs in JMF 2.0 support the reception and transmission of RTP 
streams and address the needs of application developers who want to use 
RTP to implement media streaming and conferencing applications. These 
APIs are designed to: 

• Enable the development of media streaming and conferencing 
applications in Java 

• Support media data reception and transmission using RTP and RTCP 

• Support custom packetizer and depacketizer plug-ins through the 
JMF 2.0 plug-in architecture. 

• Be easy to program 
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Partners in the Development of the JMF API 

The JMF 2.0 API is being jointly designed by Sun Microsystems, Inc. and 
IBM Corporation. 

The JMF 1.0 API was jointly developed by Sun Microsystems Inc., Intel 
Corporation, and Silicon Graphics, Inc. 

Contact Information 

For the latest information about JMF, visit the Sun Microsystems, Inc. 
website at: 

http : //j ava . sun . com/products/ j ava-medi a/ jmf / 

Additional information about JMF can be found on the IBM Corporation 
website at: 

h t tp : //www . software . i bm . com/net . medi a/ 



About this Document 

This document describes the architecture and use of the JMF 2.0 API. It 
replaces the Java Media Player Guide distributed in conjunction with the 
JMF 1.0 releases. 

Except where noted, the information in this book is not implementation 
specific. For examples specific to the JMF reference implementation devel- 
oped by Sun Microsystems and IBM corporation, see the sample code and 
solutions available from Sun's JMF website (http://java. sun . com/prod- 
ucts/ j ava-medi a/ jmf /i ndex . html ). 

Guide to Contents 

This document is split into two parts: 

• Part 1 describes the features provided by the JMF 2.0 API and 
illustrates how you can use JMF to incorporate time-based media in 
your Java applications and applets. 

• Part 2 describes the support for real-time streaming provided by the 
JMF RTP APIs and illustrates how to send and receive streaming 
media across the network. 
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Part 1 is organized into six chapters: 

• "Working with Time-Based Media"-sets the stage for JMF by 
introducing the key concepts of media content, presentation, 
processing, and recording. 

• ^ndeKtandmgJMF'-^^ 
nigh-level architecture of the framework. 

• "Presenting Time-Based Media with JMF'-describes how to use 
JMF Players and Processors to present time-based media. 

• "Processing Time-Based Media with JMF'-describes how to 
manipulate media data using a JMF Processor. 

• "Capturing Time-Based Media with JMF"— describes how to record 
media data using JMF DataSources and Processors. 

• "Extending JMF"— describes how to enhance JMF functionality by 
creating new processing plug-ins and implementing custom JMF 
classes. 

Part 2 is organized into six chapters: 

• "Working with Real-Time Media Streams"-provides an overview of 
streaming media and the Real-time Transport protocol (RTP). 

• "Understanding the JMF RTP API"— describes the JMF RTP APIs. 

• "Receiving and Presenting RTP Media Streams"— illustrates how to 
handle RTP Client operations. 

• "Transmitting RTP Media Streams"— illustrates how to handle RTP 
Server operations. 

• "ImportmgandExportingRTPMediaStreams"— shows how to read 
and write RTP data to a file. 

• "Creating Custom Packetizers and Depacketizers"— describes how 
to use JMF plug-ins to support additional RTP packet formats and 
codecs. 

At the end of this document, you'll find Appendices that contain complete 
sample code for some of the examples used in these chapters and a glos- 
sary of JMF-specific terms. & 
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Change History 

Version JMF 2.0 FCS 

• Fixed references to TrackControl methods to reflect modified 
TrackControl API. 

• Fixed minor sample code errors. 

• Clarified behavior of cloneable data sources. 

• Clarified order of events when writing to a file. 
Version 0.9 

Internal Review Draft 

Version 0.8 

JMF 2.0 Beta draft: 

• Added an introduction to RTP, Working with Real-Time Media 
Streams, and updated the RTP chapters. 

• Updated to reflect API changes since the Early Access release. 

• Added an example of registering a plug-in with the PI uglnManager. 

• Added chapter, figure, table, and example numbers and changed the 
example code style. 

Version 0.7 

JMF 2.0 Early Access Release 1 draft: 

• Updated and expanded RTP chapters in Part 2. 

• Added Demultiplexer example to "Extending JMF". 

• Updated to reflect API changes since the public review. 
Version 0.6 

Internal Review Draft 
Version 0.5 

JMF 2.0 API public review draft. 

• Added new concepts chapter, "Working with Time-Based Media". 

• Reorganized architecture information in "Understanding JMF". 
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• Incorporated RTP Guide as Part 2. 
Version OA 

JMF 2.0 API licensee review draft. 
Comments 

Please submit any comments or suggestions you have for improving this 
document to jmf -comments@eng - sun . com. 
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Working with 
Time-Based Media 



Any data that changes meaningfully with respect to time can be character- 
ized as time-based media. Audio clips, MIDI sequences, movie dips, and 
animations are common forms of time-based media. Such media data can 
be obtained from a variety of sources, such as local or network files, cam- 
eras, microphones, and live broadcasts. 

This chapter describes the key characteristics of time-based media and 
describes the use of time-based media in terms of a fundamental data pro- 
cessing model: 






Process 

mm Apply effect filters 

Read from a file A<-*A Compress or decompress 
Receive from 

the network A * B Convert between formats 




Output 



Present 

Save to a file 

Send across 
the network 



Figure 1-1: Media processing model. 
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Streaming Media 

A key characteristic of time-based media is that it requires timely delivery 
and processing. Once the flow of media data begins, there are strict timing 
deadlines that must be met, both in terms of receiving and presenting the 
data. For this reason, time-based media is often referred to as streaming 
media— it is delivered in a steady stream that must be received and pro- 
cessed within a particular timeframe to produce acceptable results. 

For example, when a movie is played, if the media data cannot be deliv- 
ered quickly enough, there might be odd pauses and delays in playback. 
On the other hand, if the data cannot be received and processed quickly 
enough, the movie might appear jumpy as data is lost or frames are inten- 
tionally dropped in an attempt to maintain the proper playback rate. 



Content Type 

The format in which the media data is stored is referred to as its content 
type. QuickTime, MPEG, and WAV are all examples of content types. Con- 
tent type is essentially synonymous with file type— content type is used 
because media data is often acquired from sources other than local files. 



Media Streams 

A media stream is the media data obtained from a local file, acquired over 
the network, or captured from a camera or microphone. Media streams 
often contain multiple channels of data called tracks. For example, a 
Quicktime file might contain both an audio track and a video track. Media 
streams that contain multiple tracks are often referred to as multiplexed or 
complex media streams. Demultiplexing is the process of extracting individ- 
ual tracks from a complex media stream. 

A track's type identifies the kind of data it contains, such as audio or 
video. The format of a track defines how the data for the track is struc- 
tured. 

A media stream can be identified by its location and the protocol used to 
access it. For example, a URL might be used to describe the location of a 
QuickTime file on a local or remote system. If the file is local, it can be 
accessed through the FILE protocol. On the other hand, if if s on a web 
server, the file can be accessed through the HTTP protocol. A media locator 
provides a way to identify the location of a media stream when a URL 
can't be used. 
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Media streams can be categorized according to how the data is delivered: 

• Pull-^data transfer is initiated and controlled from the client side For 
pSZds ^^^^^^(f^)^ FILE are pull' 

• Push-the server initiates data transfer and controls the flow of data 
For example, Real-time Transport Protocol (RTP) is a push protocol ' 
used for streaming media. Similarly, the SGI MediaBase protocol is a 
push protocol used for video-on-demand (VOD). P 

Common Media Formats 

f? C f ^J 68 S ° me ° f ^^ristics of common media 

formate. When selecting a format, if s important to take into account the 
charactensbcs of the format, the target environment, and the expectations 
of the intended audience. For example, if you're delivering media content 
via the web, you need to pay special attention to the bandwidth require- 
ments. ^ 

The CPU Requirements column characterizes the processing power neces- 
sary for optimal presentation of the specified format The Bandwidth 
Requirements column characterizes the transmission speeds necessary to 
send or receive data quickly enough for optimal presentation. 



Format 


Content Type 


Quality 


CPU 
Requirements 


Bandwidth 
Requirements 


Cinepak 


AVI 

QuickTime 


Medium 


Low 


High 


MPEG-1 


MPEG 


High 


High 


High 


H.261 


AVI 
RTP 


Low 


Medium 


Medium 


H.263 


QuickTime 

AVI 

RTP 


Medium 


Medium 


Low 










JPEG 


QuickTime 
AVI 


High 


High 


High 



RTP 
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Format Content Type Quality 



CPU Bandwidth 
Requirements Requirements 




Medium 



Medium 



Table 1-1: Common video formats. 



Format Content Type Quality 



Mu-Law 



ADPCM 

(DVI, 

IMA4) 



MPEG-1 

MPEG 
Layer3 

GSM 
G.723.1 



AVI 

QuickTime 
WAV 

AVI 

QuickTime 

WAV 

RTF 

AVI 

QuickTime 

WAV 

RTP 

MPEG 

MPEG 



WAV 
RTP 

WAV 
RTP 



High 



Low 



CPU Bandwidth 
Requirements Requirements 

Low High 



Low 



High 



Medium Medium 



Medium 



High 
High 



High 
High 



Low Low 
Medium Medium 



High 
Medium 

Low 

Low 



Table 1-2: Common audio formats. 

fn ZlT^X with particular applications and requirements 

in mind High-quality, high-bandwidth formats are generally targeted 
toward CD-ROM or local storage applications. H.261 and H.263 are gener- 
ally used for video conferencing applications and are optimized for video 
where there's not a lot of action. Similarly, G.723 is typically used to pro- 
duce low bit-rate speech for telephony applications 
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Media Presentation 



Most time-based media is audio or video data that can be presented 
tfjrough output devices such as speakers and monitors. SuSTvKs are 
the most common destination for media data output. Media stream?^ 
also be sent to other destinations-f or example Led toTfiW^ • 
ted across the network An output desS^ SS^ST* 
times referred to as a data sink. 



Presentation Controls 



While a media stream is being presented, VCR-style presentation controls 
are often provided to enable the user to control playback For examrfe a 
fa?rol p an^ 

fast-forwarding, and rewinding the movie. * waning, 



Latency 



In many cases particularly when presenting a media stream that resides 
on the network, the presentation of the media stream cannot beeinlmml 

start latency. Users might experience this as a delay between the time that 
they click the start button and the time when playback actually stStl 

Multimedia presentations often combine several types of time-based 
Z£?£ t0 i a S> T? r0niZed P«nfaticn. For example, background music 
might be played during an image slide-show, or animated text might be 

TlZT Z6 l aU ?° ° r ^ di P- men Ae Presentation of multi- 

ple media streams is synchronized, it is essential to take into account the 
start latency of each stream-otherwise the playback of the different 
streams might actually begin at different times. 

Presentation Quality 

The quality of the presentation of a media stream depends on several fac- 
tors, including: 

• The compression scheme used 

• The processing capability of the playback system 

• The bandwidth available (for media streams acquired over the 
network) 
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Traditionally, the higher the quality, the larger the file si^ a 
Media Processing 

1. If the stream is multiplexed, the individual tracks are extracted. 

2. If the individual tracks are compressed, they are decoded. 

3. If necessary, the tracks are converted to a different format. 

4. Effect filters are applied to the decoded tracks (if desired). 

The^tracks are then delivered to the appropriate output device If the 

or e ±« T 18 10 * f t0red ^ered to I ou^Tde Jce the 

For example, if yoLan^^. 
toeaudio and video from a video camera, process the data, and save it to 

1. The audio and video tracks would be captured. 

2. Effect filters would be applied to the raw tracks (if desired). 

3. The individual tracks would be encoded. 

4 " ^ e eam mPreSSed ™* d * multi P lexed mto a single media 

5. The multiplexed media stream would then be saved to a file. 
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Demultiplexers and Multiplexers 

A demultiplexer extracts individual tracks of media 

Plexed media stream. A nrnOf^ perf^ SE££Z£?t 



Codecs 



Each codec has certain input formats that it can handle and certain o,,hw 

formats thatit can generate, m some situation^ 

used to convert from one format to another. ^ 

Effect Filters 

Effert filters are classified as either pre-processing effects or post-process- 
^effects, depending on whether they are applied before or ate^T 

p^^t^^^^™^-™ 
Renderers 

A renderer is an abstraction of a presentation device. For audio, the pre- 
sentation device ,s typically the computer's hardware audio card ^ out- 
puts sound to the speakers. For video, the presentation device is My 
the computer monitor. y * /lu<m / 

Compositing 

Certain specialized devices support compositing. Compositing time-based 
media is the process of combining multiple tracks of data onto a single 
presentation medium. For example, overlaying text on a video presenta- 
taon is one common form of compositing. Compositing can be done in 

r!!!'^^ 316 01 J 80ftw f e - A device ^ T{orms compositing can be 
abstracted as a renderer that can receive multiple tracks of input data 
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Media Capture 



Capture Devices 



To capture time-based media you need specialized hardware-for exam 
pie, to capture audio from a live source, you need a m,V™W^ J 
appropriate audio card. Similarly, captuXg .^SS^ a^TV 
tuner and an appropriate video capture card. Most systems Sa 
query mechanism to find out what capture devices a£ SST 

Capture devices can be characterized as either push or pull sources For 
exampHastillcameraisapullsource-theui controk wh™ a puL 
an image. A microphone is a push source-the live source corSnuousrT 
provides a stream of audio. <-"nnnuousiy 

forl^A 3 C T U ^ mCdia Stieam depends on me P^ing per- 
formed by the capture device. Some devices do very little processing and 
de hver raw, uncompressed data. Other capture devices might dSme 
data in a compressed format. me 

Capture Controls 

Controls are sometimes provided to enable the user to manage the capture 
process. For example, a capture control panel might enable *e us£ to 

and stop the capture process. 



Understanding JMF 



Java™ Media Framework (JMF) provides a unified architecture and mes- 
2 P^^^ging the acquisition, processing, and deKver^f 
tme-based media data. JMF is designed to support most standard media 



S oP^riW^ a l Vant fS eS ° f ** ' ava P latf °nn, JMF delivers the prom- 
ise of Write Once, Run Anywhere™" to developers who want to use 
media such as audio and video in their Java programs. JMF provides a 

ZS 0 ?^^ atf0rm ^ ^ f ° r aCC6SSin S deriving media frame- 
works. JMF implementations can leverage the capabilities of the underly- 
ing operating system, while developers can easily create portable Java 
programs that feature time-based media by writing to the JMF API. 

With JMF, you can easily create applets and applications that present, cap- 
ture, manipulate, and store time-based media. The framework enables 
advanced developers and technology providers to perform custom pro- 
cessing of raw media data and seamlessly extend JMF to support addi- 
tional content types and formats, optimize handling of supported formats 
and create new presentation mechanisms. 

High-Level Architecture 

Devices such as tape decks and VCRs provide a familiar model for record- 
ing, processing, and presenting time-based media. When you play a movie 
using a VCR, you provide the media stream to the VCR by inserting a 
video tape. The VCR reads and interprets the data on the tape and sends 
appropriate signals to your television and speakers. 
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Video camera 

(Capture Device) 




Video tape 

(Data Source) 



VCR 

(Player) 




Output Devices 

microphones, cameras, speakers, and monitors. 

Data sources and players are integral parts of JMFs high-level API for 
managmg the capture, presentatioa and processing of talbteYrSdia 
m ato provdes a lower-level API that supports fte seamle^megra 
bono custom processmg components and extensions. TWs layerinlL- 
vides Java developers with an easy-to-use API for incorporaftl toe? 
based media mto Java programs while maintaining theflexftuitVa^d 
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Figure 2-2: High-level JMF achitecture 



Time Model 



JMF keeps lime to nanosecond precision. A particular point in time is tvp- 
specification of hme in nanoseconds. "F^rtme 

toZbSZZSX* ""^ toe ^ im P lem «* "ock to keep track of 
T^JiS^L^ saeam -^ Clock interface defines the basic 

>perabons that are needed to control the pre- 



sentation of media data. 




Clock 


has 




syncStart 






stop 






getMediaTime 






setMediaTime 






getRate 






setRate 






getStopTime 






setStopTime 






getTimeBase 






setTimeBase 




Figure 2-3: JMF time model. 



TimeBase 



getTime 

getNanoseconds 



Time 



Time (long nanoseconds) 
Time (double seconds) 
getNanoseconds 
getSeconds 

secondsToNanoseconds 



Duration 



getDuration 



A Cl ock uses a Ti me Base to keep track of the passage of time while a media 
stream is being presented. A TimeBase provides a constantly ticking time 
source much like a crystal oscillator in a watch. The only information that 
a Ti meBase provides is its current time, which is referred to as the time-base 



time. The time-base time cannot be stopped or reset Tim* h aca « • 
often based on the system clock. Tune-base time is 

A Clock object's mafti time represents the current position wifhin * ^ - 
sfream-the beginning of the stream is media me zeTSTe^d of E* 8 
stream is the maximum media time for the stre^ ^edurlti^n of t 
media s^eam is the elapsed time from start to fi^h^ht len^Tme 
that it takes to present the media stream. (Media object m2™°! T 
Duration interface if they can -port a media str^ 
To keep track of the current media time, a CI ock uses: 

" P^^ 

# Sat^ 

• The playback rate-how fast the dock is running in relation to its 
TuneBase. The rate is a scale factor that is applied to the TimTefse For 
example a rate of 1.0 represents the normal playback rate for *e 
media stream, while a rate of 2.0 indicates that the presentation will 
runattwu*^ 

running in the opposite direction from its Ti meBase-for example a 
negative rate might be used to play a media stream backward ' 

When presentation begins, the media time is mapped to the time-base 
time and the advancement of the time-base time is used to measure the 
passage of time. During presentation, the current media time is calculated 
using the following formula: «-ui«eu 

MediaTime = MediaStartTime + RateCTimeBaseTime - TimeBaseStartTime) 

When the presentation stops, the media time stops, but the time-base time 
continues to advance. If the presentation is restarted, the media time is 
remapped to the current time-base time. 

Managers 

The JMF API consists mainly of interfaces that define the behavior and 
mterachon of objects used to capture, process, and present time-based 
media. Implementations of these interfaces operate within the structure of 
the framework. By using intermediary objects called managers, JMF makes 
it easy to integrate new implementations of key interfaces that can be used 
seamlessly with existing classes. 



Understanding JMF 

JMF uses four managers: 



is 



Manager-handles the construction of Players, Processors 
DataSources, and DataSinks. This level of indirection allows new 
implementations to be integrated seamlessly with JMF. From the client 
perspective , these objects are always created the same waTwhemeT 

£sto^ 

• PackageManager-maintains a registry of packages that contain IMF 
D^nks ^ CUSt ° m Pl3yerS ' PrOC6SSOrS ' Source" 

• devils 60 eV1CeManager - maintains a registry of available capture 

• PI uglnManager— maintains a registry of available IMF plue-in 
Pressing components, such as Multiplexers, Demultiplexers 
Codecs, Effects, and Renderers. 

"fW^ ^ on JMF, you'll need to use the Manager create 
methods to construct Ae Players, Processors, DataSources, and DataSinks 
1°*?™ a PP h r cabon ' * y° u ^ capturing media data from an input device 
you 11 use the CaptureDeviceManager tofind out what devices are available 
and access inf ormanon about them. If you're interested in controlUng 
what processing is performed on the data, you might also query the PI ug- 
lnManager to determine what plug-ins have been registered. 

ctionaIit y h Y implementing a new plug-in, you can 
register it with the PI uglnManager to make it available to Processors that 
support the plug-in API To use a custom Player, Processor, DataSource 
or DataSi nk with :MF, you register your unique package prefix with the ' 



Event Model 



JMF uses a structured event reporting mechanism to keep JMF-based pro- 
grams informed of the current state of the media system and enable JMF- 
based programs to respond to media-driven error conditions, such as out- 
of data and resource unavailable conditions. Whenever a JMF object needs 
to report on the current conditions, it posts a Medi aEvent. MedT aEvent is 
subclassed to identify many particular types of events. These objects fol- 
low the established Java Beans patterns for events. 
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For each type of JMF object that can post Med, aEvents, IMF defines a m™ 
spending tetener interface. To receive notification when! *S ? 

Ustener cUss vv.tr. the object that posts the event by calling SSST 



MediaEvent 



Controller 

addControl 1 erLi stener 
removeCont roll erLi stener 


__ nas a . 1 Control lerListeneF 1 ^ 

j control! e rUpdate (Control! erEvent) 


\ exte 


creates 
► 


Control 1 erEvent 








getSourceCont roller 



'^r° n !!* na9er 0b,eCtS 3180 P° St events - For more information, 
TOT Events" on page 122. 



see 



Data Model 



JMF media players usually use DataSources to manage the transfer of 
media-content. A DataSource encapsulates both the location of media and 
the protocol and software used to deliver the media. Once obtained the 
source cannot be reused to deliver other media. 

A DataSource is identified by either a JMF MediaLocator or a URL (univer- 
sal resource locator). A Medi aLocator is similar to a URL and can be con- 
structed from a URL, but can be constructed even if the corresponding 
protocol handler is not installed on the system. (In Java, a URL can only be 
constructed if the corresponding protocol handler is installed on the svs- 
tern.) * 

A DataSource manages a set of SourceSt ream objects. A standard data 
source uses a byte array as the unit of transfer. A buffer data source uses a 
Buffer object as its unit of transfer. JMF defines several types of Data- 
Source objects: 
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[ Controls J | Duration | 

n a ^ a ^ llrcc I manages one or more i 

' I I *1 SourceStream I 



- jpullDataSource | 



|uRLDataSource ~] 
- ] Pu 11 Buff e rDataSou rce J 
- jpushDataSource | 
- | PushBufferDataSourcTJ 



Pull Source Stream I 
|lnputSourceStream j 



PullBufferStreamJ 
PushSourceStream | 
PushBufferStreamj 



Figure 2-5: JMF data model. 
Push and Pull Data Sources 

Media data can be obtained from a variety of sources, such as local or net- 
work files and live broadcasts. JMF data sources can be categorized 
according to how data transfer is initiated: 

• Pull Data-Source-lhe client initiates the data transfer and controls the 

flow of data frompull data-sources. Established protocols forthistvpe 

of data include Hypertext Transfer Protocol (HTTP) and FILE IMF 

defines two types of pull data sources: PuHDataSource and 

Pull Buff erDataSource, which uses a Buffer object as its unit of 
transfer. 

• Push Data-Source-the server initiates the data transfer and controls 
the flow of data from a push data-source. Push data-sources include 
broadcast media, multicast media, and video-on-demand (VOD) For 
!£™ Cast data ' one P rot <>col is the Real-time Transport Protocol 

nmx ^ x r /! Ve i° pment by * e Internet peering Task Force 
(IETF^eMediaBaseprotocol developed by SGIis one protocol used 
for VOD. JMF defines two types of push data sources: PushDataSource 
and PushBuff erDataSource, which uses a Buffer object as its unit of 
transfer. 



The degree of control that a client program can extend to the user depends 
on the type of data source being presented. For example, an MPEG file can 



18 



JMF API Guide 



be repositioned and a client program could allow the user to reolav 
video clip or seek to a new position in the video. In c^nSs fflf 



Specialty DataSources 

^^sss^r^ data sources - doneabie d - «— 

A doneabie data source can be used to create clones of either a pull or 
push DataSource. To create a doneabie DataSource you cTthe 

rr cl ?r bl eDatasou rce method p« - 

to clone. Once a DataSource has been passed to created oneabl eData 
Source you should only interact with the doneabie DataSource and its 
clones; the original DataSource should no longer be used dirertly 

2fin C pfnn ** Sourcedoneable interface, which 

defines one method, createdone. By calling createClone, you can creaTe 

doneabie DataSource. The dones can be controlled through the doneabie 
DataSource used to create them- when connect, disconnect, starTor 

^tot^^ 

The dones don't necessarily have the same properties as the doneabie 

tG aMte or ori S^ DataSource. For example, a 
doneabie data source created for a capture device might function as a 
master data source for its dones-in this case, unless the doneabie data 
source is used, the dones won't produce any data. If you hook up both the 
doneabte data source and one or more dones, the dones will produce 
data at the same rate as the master. 

A MergingDataSource can be used to combine the SourceStreams from sev- 
eral DataSources into a single DataSource. This enables a set of Data- 
Sources to be managed from a single point of control-when connect 
d! sconnect, start, or stop is called on the MergingDataSource, the method 
calls are propagated to the merged DataSources. 

To construct a MergingDataSource, you call the Manager createMerging- 
DataSource method and pass in an array that contains the data sources 
you want to merge. To be merged, all of the DataSources must be of the 
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Data Formats 

fo^HlT^ f0rmat ° f ^ 0bjeCt iS re P^ted by a Format object The 
format iteelf carries no encoding-specific parameters or global tinSe 

JMF extends Format to define audio- and video-specific formats. 



Format 



3: 



AudioFormat J 



FormatControl 



Vi deoFormat 

3 



J 



get Format 
set Format 

getSupportedFormats 
is Enabled 
| set Enabled 



IndexedCol or Format | 



RCBFormat 



] 



YUVFormat 



JPEGFormat 



H261Format 



H263 Format 



] 



Figure 2-6: JMF media formats. 

An Audi oFormat describes the attributes specific to an audio format, such 
as samp e rate, bits per sample, and number of channels. A VideoFormat 
encapsulates information relevant to video data . Several formats are 

denvedfrom VideoFormat to describe the attributes of common video 
formats, including: 

• IndexedColorFormat 

• RCBFormat 

• YUVFormat 

• JPEGFormat 

• H261Format 

• H263Format 



20 



JMF API Guide 

To receive notification of format changes from a Control 1 er, you imple- 
ment the Control! erLi stener interface and listen for FormatChangeEvents 
(For more information, see "Responding to Media Events" on page 54.) 

Controls 

JMF Control provides a mechanism for settingand querying attributes of 
an object. A Control often provides access to a corresponding user inter- 
face component that enables user control over an object's attributes Many 
JMF objects expose Control s, including Controll er objects, DataSource 
objects, DataSi nk objects, and JMF plug-ins. 

Any JMF object that wants to provide access to its corresponding Control 
objects can implement the Controls interface. Controls defines methods 
for retrieving associated Control objects. DataSource and Plugln use the 
Control s interface to provide access to their Control objects. 

Standard Controls 

JMF defines the standard Control interfaces shown in Figure 2-8- "JMF 
controls." 

CachingControl enables download progress to be monitored and dis- 
played. If a Player or Processor can report its download progress, it 
implements this interface so that a progress bar can be displayed to the 
user. 

CainControl enables audio volume adjustments such as setting the level 
and muting the output of a PI ayer or Processor. It also supports a listener 
mechanism for volume changes. 



MediaEvent 



has one or more 



CainControl 




Cai nCnangeLi stener 






addGai nCnangeLi stener 
removeCai nCnangeLi stener 




gai nChange(Gai nChangeEvent) 








creates 

. h. 












Gai nChangeEvent 






getDB 

getLevel 

getMute 



extends 



Figure 2-7: Gain control. 
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Control 



-|BitRateContro1 
- jBufferControl 
- jcachi ngControl 
■j FormatControl 



1 [TrackControl j 

["FrameGrabbi ngControl J 
"FramePositioni ngControl J 
FrameProces s i ngCont rol "| 
FrameRateControT { 
-|cainContro1 | 
- jH263Contro1 
- |H261Contro1 ~"| 
- jKeyFrameControl ~| 
- jMonitorControl | 
- jMpegAudioControl j 
\ PacketSizeControl] 
PortControl | 

jQualityControl J 

— 1 RTTControl | 

— " jSilenceSuppressionControl] 

I— 1 StreairtWriterControl | 

Figixre 2-8: JMF controls. 

DataSink or Multiplexer objects that read media from a DataSource and 
write it out to a destination such as a file can implement the StreamWri t- 
erControl interface. This Control enables the user to limit the size of the 
stream that is created. 

FramePositioni ngControl and FrameCrabbi ngControl export frame-based 
capabilities for Players and Processors. FramePositioni ngControl enables 
precise frame positioning within a PI ayer or Processor object's media 
stream. FrameCrabbi ngControl provides a mechanism for grabbing a still 
video frame from the video stream. The FrameCrabbi ngControl can also be 
supported at the Renderer level. 



Objects that have a Format can implement the FormatControl interface to 
provide access to the Format. FormatContro! also provides memcS for 
querymg and setting the format. «noosior 

foJrnn^ir ^ t V** ° f ForrnatContro1 PwvMes the mechanism 
for conning what processing a Processor object performs on a particu- 
lar track of media data. With the TrackControl methods, you can S 
what format conversions are performed on individual tracks and select 
the Effect, Codec, or Renderer plug-ins that are used by the Processor 
(For more information about processing media data, see "Processing ' 
Time-Based Media with JMF" on page 71.) 

Two controls, PortControl and MonitorControl enable user control over 
the capture process. PortControl defines methods for controlling the out- 
put of a capture device. Moni torControl enables media data to be pre- 
viewed as it is captured or encoded. 

ticulaT objert 01 enaWeS USer " leVel C ° ntro1 ° Ver buffe *ing done by a par- 

JMF also defines several codec controls to enable control over hardware or 
software encoders and decoders: 

• Bi tRateControl— used to export the bit rate information for an 
incoming stream or to control the encoding bit rate. Enables 
specification of the bit rate in bits per second. 

• FrameProcessi ngControl— enables the specification of frame 
processing parameters that allow the codec to perform ininimal 
processing when it is falling behind on processing the incoming data. 

• FrameRateControl— enables modification of the frame rate. 

• H261Control— enables control over the H.261 video codec still-imaee 
transmission mode. 

• H263Cont rol— enables control over the H.263 video-codec parameters 
including support for the unrestricted vector, arithmetic coding, 
advanced prediction, PB Frames, and error compensation extensions. 

• KeyFrameControl— enables the specification of the desired interval 
between key frames. (The encoder can override the specified key- 
frame interval if necessary.) 

• MpegAudioControl— exports an MPEG audio codec's capabilities and 
enables the specification of selected MPEG encoding parameters. 

• Qua! i tyCont rol— enables specification of a preference in the trade-off 
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between, quality and CPU usage in the processing performed by a 
codec This quality hint can have different effects depending on the 
type of compression. A higher quality setting will result in better 
quahty of the resulting bits, for example better image quality for 

SilenceSuppressionControl-enables specification of silence 
suppression parameters for audio codecs. When silence suppression 
mode is on, an audio encoder does not output any data if it detects 
silence at its input. 
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User Interface Components 

A Control can provide access to a user interface Component that exposes its 
control behavior to the end user. To get the default user interface compo- 
nent for a particular Control, you call getControl Component. This method 
returns an AWT Component that you can add to your applet's presentation 
space or application window. v 

A Controller might also provide access to user interface Components For 
example, a PI ayer provides access to both a visual component and a con- 
trol panel component— to retrieve these components, you call the Player 
methods getVisual Component and getControl Panel Component. 

If you don't want to use the default control components provided by a 
particular implementation, you can implement your own and use the 
event listener mechanism to determine when they need to be updated. For 
example, you might implement your own GUI components that support 
user interaction with a PI ayer. Actions on your GUI components would 
trigger calls to the appropriate Player methods, such as start and stop. 
By registering your custom GUI components as Control 1 erLi steners for 
the PI aye r, you can also update your GUI in response to changes in the 
Player object's state. 



Extensibility 

Advanced developers and technology providers can extend JMF function- 
ality in two ways: 

• By implementing custom processing components (plug-ins) that can be 
interchanged with the standard processing components used by a JMF 
Processor 



• By directly implementing the Controller, Player, Processor 
DataSource, or DataSi nk interfaces 

SST? 8 3 ^ ^ T HeS y ° U to CU8tanri « or ext ^d the capa- 
bikfaes of a Processor without having to implement one from scratch T 

Once a plug-m is registered with JMF, it can be selected as a processing 
bTusTd I to: 3 " 7 Pr ° CeSSOr ** SUPPOrtS Ae plUg " in ^ Wins can 

• ExtendorreplaceaProcessorobject-sprocessingcapabiUtypiecewise 
by selectmg the individual plug-ins to be used. /P 

• Access the media data at specific points in the data flow. For example 
different Effect plug-ins can be used for pre- and post-processing of 
me media data associated with a Processor. 

• ProcessmediadataoutsideofaPlayerorProcessor.Forexample you 
might use a Demultiplexer plug-in to get individual audio tracks from 
amultiplexed media-stream so you could play the tracks through Java 



In situations where an even greater degree of flexibility and control is 
required, custom implementations of the JMF Controller, Player Proces- 
sor, DataSource, or DataSi nk interfaces can be developed and used seam- 
lessly with existing implementations. For example, if you have a 
hardware MPEG decoder, you might want to implement a Player that 
takes input from a DataSource and uses the decoder to perform the pars- 
ing, decoding, and rendering all in one step. Custom PI ayers and Proces- 
sors can also be implemented to integrate media engines such as 
Microsoft's Media Player, Real Network's RealPlayer, and IBM's HotMe- 
dia with JMF. 

Note: JMF Players and Processors are not required to support plue-ins 
P ug-ins won't work with JMF 1.0-based PI ayers and some Processor im- 
plementations might choose not to support them. The reference imple- 
mentation of JMF 2.0 provided by Sun Microsystems, Inc. and IBM 
Corporation fully supports the plug-in API. 

Presentation 

In JMF, the presentation process is modeled by the Controller interface 
Controll er defines the basic state and control mechanism for an object 
that controls, presents, or captures time-based media. It defines the phases 
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that a media controller goes through and provides a mechanism for con- 
trolling the transitions between those phases. A number of the operations 
that must be performed before media data can be presented can be time 
consuming, so JMF allows programmatic control over when they occur. 

AController posts a variety of controller-specific Medi aEvents to provide 
notification of changes in its status. To receive events from a Control 1 er 
such as a Player, you implement the Control! erLi stener interface For 
more information about the events posted by a Controller, see ''Control 
ler Events" on page 30. 

The JMF API defines two types of Controllers: Players and Processors A 
PI ayer or Processor is constructed for a particular data source and is nor- 
mally not re-used to present other media data. 
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Figure 2-9: JMF controllers. 



Players 

A PI ayer processes an input stream of media data and renders it at a pre- 
cise time. A DataSource is used to deliver the input media-stream to the 
PI ayer.The rendering destination depends on the type of media being pre- 
sented. ° r 




Figure 2-10: JMF player model. 
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A PI ayer does not provide any control over the processing that it performs 
or how it renders the media data. 

PI aye r supports standardized user control and relaxes some of the opera- 
tional restrictions imposed by Clock and Controller. 

has a 



Clock 



syncStart 
stop 

getMediaTime 
getTimeBase 
setTimeBase 
setRate 



5 



TimeBase 



Duration 



extends 



Controller 

prefetch 
realize 
deallocate 
close 

addControl 1 erListener 



getDuration 



.extends 



3 



.extends 



MediaHandler 



setSource 

5 



.extends 



Figure 2-11: JMF players. 



Player 


has a 


Dataiource 


start 
setSource 






addCont roller 




getVi sual Component 




getControl Panel Component 





Player States 

A PI ayer can be in one of six states. The CI ock interface defines the two 
primary states: Stopped and Started. To facilitate resource management, 
Controller breaks the Stopped state down into five standby states: Unreal- 
ized, Realizing, Realized, Prefetching, and Prefetched. 



Stopped Started 




Transitbn Events: 

RCE RealizeCompleteEvent 
PFCE PrefetchCompfateEvent 
SE StopEvent 



Figure 2-12: Player states. 
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In normal operation, a Player steps through each state until it reaches the 
started state: 

• A PI ayer in the Unrealized state has been instantiated, but does not vet 
know anything about its media. When a media PI ayer is first created 
it is Unrealized. 

• When realize iscalle^ 

the Realizing state. A Realizing PI ayer is in the process of detenrunin* 
its resource requirements. During realization, a Player acquires the 
resources that it only needs to acquire once. These might include 
rendering resources other than exclusive-use resources. (Exclusive- 
use resources are limited resources such as particular hardware 
devices that can only be used by one Player at a time; such resources 
are acquired during Prefetching.) A Realizing Player often downloads 
assets over the network. 

• When a PI ayer finishes Realizing, it moves into the Realized state. A 
Realized PI ayer knows what resources it needs and information about 
the type of media it is to present. Because a Realized PI ayer knows how 
to render its data, it can provide visual components and controls. Its 
connections to other objects in the system are in place, but it does not 
own any resources that would prevent another PI ayer from starting. 

• When prefetch is called, a PI ayer moves from the Realized state into 
the Prefetching state. A Prefetching PI ayer is preparing to present its 
media. During this phase, the PI ayer preloads its media data, obtains 
exclusive-use resources, and does whatever else it needs to do to 
prepare itself to play. Prefetching might have to recur if a PI ayer 
object's media presentation is repositioned, or if a change in the PI ayer 
object's rate requires that additional buffers be acquired or alternate 
processing take place. 

• When a PI ayer finishes Prefetching, it moves into the Prefetched state. A 
Prefetched PI ayer is ready to be started. 

• Calling start puts a Player into the Started state. A Started Player 
object's time-base time and media time are mapped and its clock is 
running, though the Player might be waiting for a particular time to 
begin presenting its media data. 

A PI ayer posts Transi ti onEvents as it moves from one state to another. 
The Control 1 er Li stener interface provides a way for your program to 
determine what state a PI ayer is in and to respond appropriately. For 
example, when your program calls an asynchronous method on a PI ayer 
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or Processor, it needs to listen for the appropriate event to determine 
when the operation is complete. 

Using this event reporting mechanism, you can manage a PI ayer object's 
start latency by controlling when it begins Realizing and Prefetching. It also 
enables you to determine whether or not the Player is in an appropriate 
state before calling methods on the PI aye r . 

Methods Available in Each Player State 

To prevent race conditions, not all methods can be called on a Player in 
every state. The following table identifies the restrictions imposed by JMR 
If you call a method that is illegal in a Player object's current state, the 
PI ayer throws an error or exception. 



Method 


Unrealized 


Realized 


Prefetched 


Started 




Player 


Player 


Player 


Player 


ad dCont roller 


NotReal i zedError 


legal 


legal 


ClockStartedError 


deallocate 


legal 


legal 


legal 


ClockStartedError 


getControl Panel Component NotReal i zedError 


legal 


legal 


legal 


getCainControl 


NotReal i zedError 


legal 


legal 


legal 


getStart Latency 


NotRealizedError 


legal 


legal 


legal 


getTi meBase 


NotReal i zedError 


legal 


legal 


legal 


getVi sual Component 


NotRealizedError 


legal 


legal 


legal 


mapToTi meBase 


CI ockStopped Except i on 


CI ockStoppedException 


CI ockStoppedException 


legal 


removeCont roller 


NotRealizedError 


legal 


legal 


ClockStartedError 


setMediaTime 


NotRealizedError 


legal 


legal 


legal 


setRate 


NotRealizedError 


legal 


legal 


legal 


setStopTime 


NotRealizedError 


legal 


legal 


StopTi me Set Er ror 










if previously set 


setTi meBase 


NotRealizedError 


legal 


legal 


CI ockStartedEr ror 


syncStart 


NotPrefetchedError 


NotPrefetchedError 


legal 


CI ockStartedEr ror 


Table 2-1: 


Method restrictions for players. 
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Processors can also be used to present media data. A Processor is just a 
specialized type of PI aye r that provides control over what processing is 
performed on the input media stream. A Processor supports all of the 
same presentation controls as a PI ayer. 




Figure 2-13: JMF processor model. 



In addition to rendering media data to presentation devices, a Processor 
can output media data through a DataSource so that it can be presented by 
another Player or Processor, further manipulated by another Processor, 
or delivered to some other destination, such as a file. 

For more information about Processors, see "Processing" on page 32. 



Presentation Controls 

In addition to the standard presentation controls defined by Control 1 er, a 
PI ayer or Processor might also provide a way to adjust the playback vol- 
ume. If so, you can retrieve its Cai nControl by calling getCai nControl . A 
GainControl object posts a GainChangeEvent whenever the gain is modi- 
fied. By implementing the GainChangeLi stener interface, you can respond 
to gain changes. For example, you might want to update a custom gain 
control Component. 

Additional custom Control types might be supported by a particular 
Player or Processor implementation to provide other control behaviors 
and expose custom user interface components. You access these controls 
through the getControl s method. 

For example, the CachingControl interface extends Control to provide a 
mechanism for displaying a download progress bar. If a PI ayer can report 
its download progress, it implements this interface. To find out if a PI ayer 
supports CachingControl, you can call getControl (Cachi ngControl) or 
use getControl s to get a list of all the supported Control s. 
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Standard User Interface Components 

A Player or Processor generally provides two standard user interface 
components, a visual component and a control-panel oompo^S!«„ 

Control Panel Component methods. 9 

Jvif^f 180 im P le L ment "*r ^erface components, and use the 

event hstener mechanism to determine when they need to be updated! 

Controller Events 

Hie ControllerEvents posted by a Controller such as a Player or Proces- 
"tio" CateS ° rieS: ^ notifica *>-' closed events, and txan- 

• Change notification events such as RateChange Event 

D ^ 1 '? nU ? d u teEVent/ 3nd Fo ™atChangeEvent indicate that some 
attnbuteof the Controllers changed, often in response to a method 
call. For example, a Player posts a RateChange Event when its rate is 
changed by a call to setRate. 

• Transi tionEvents allow your program to respond to changes in a 
Controller object's state. A Player posts transition events whenever 
it moves from one state to another. (See "Player States" on page 26 for 
more information about the states and transitions.) 

• ControllerdosedEvents are posted by a Controller when it shuts 
down. When a Control 1 er posts a Control 1 erd osedEvent, it is no 
longer usable. A Contrail erErrorEvent is a special case of 
Contrail erd osedEvent. You can listen for Contrail erErrorEvents so 
that your program can respond to Controller malfunctions to 
minimize the impact on the user. 
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Figure 2-14: JMF events. 
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A Processor is a Player that takes a DataSource as input, performs some 
user-defined processing on the media data, and then outputs the pro- 
cessed media data. v v 

has a 



Player 



start 
setSource 
addCont roller 
getVi sua! Component 
getControl Panel Component 
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uataSource 
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getTrackControls 
getSupportedContentDescri ptors 
setOutputContentDescri ptor 
getOutputContentDescri ptor 
getOataOutput 



creates a. 



uataSource 



3 



Figure 2-15: JMF processors. 

A Processor can send the output data to a presentation device or to a 
DataSource. If the data is sent to a DataSource, that DataSource can be used 
as the input to another PI ayer or Processor, or as the input to a DataSi nk. 

While the processing performed by a PI aye r is predefined by the imple- 
mentor, a Processor allows the application developer to define the type of 
processing that is applied to the media data. This enables the application 
of effects, mixing, and compositing in real-time. 

The processing of the media data is split into several stages: 




Processor 



Figure 2-16: Processor stages. 



• Demultiplexing is the process of parsing the input stream. If the 
stream contains multiple tracks, they are extracted and output 
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separately. For example, a QuickTime file might be demultiplexed 
mto separate audio and video tracks. Demultiplexing is performed 
automatically whenever the input stream contains multiplexed data. 

• Pre-Processing is the process of applying effect algorithms to the 
tracks extracted from the input stream. 

• Transcodingis the process of converting each track of media data from 
one input format to another. When a data stream is converted from a 
compressed type to an uncompressed type, it is generally referred to 
as decoding. Conversely, converting from an uncompressed type to a 
compressed type is referred to as encoding. 

• Post-Processing is the process of applying effect algorithms to 
decoded tracks. 

• Multiplexing is the process of interleaving the transcoded media 
tracks into a single output stream. For example, separate audio and 
video tracks might be multiplexed into a single MPEG-1 data stream 
You can specify the data type of the output stream with the Processor 
setOutputContentDescriptor method. 

• Rendering is the process of presenting the media to the user. 

The processing at each stage is performed by a separate processing com- 
ponent. These processing components are JMF plug-ins. If the Processor 
supports TrackControl s, you can select which plug-ins you want to use to 
process a particular track. There are five types of JMF plug-ins: 

• Demul ti plexer— parses media streams such as WAV, MPEG or 
QuickTime. If the stream is multiplexed, the separate tracks are 
extracted. 

• Effect— performs special effects processing on a track of media data. 

• Codec — performs data encoding and decoding. 

• Mul ti pi exer—combines multiple tracks of input data into a single 
interleaved output stream and delivers the resulting stream as an 
output DataSource. 

• Renderer— processes the media data in a track and delivers it to a 
destination such as a screen or speaker. 



Processor States 



A Processor has two additional standby states, Configuring and Config- 
ured, which occur before the Processor enters the Realizing state.. 
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deallocate 

Transition Events: 
CCE ConfigureCompleteEverit 
RCE RealizeCornptsteEvent 
PFCE PrefstcnCompteteEvent 
SE StopEvent 

Figure 2-17: Processor states. 

• A Processor enters the Configuring state when configure is called. 
While the Processor is in the Configuring state, it connects to the 
DataSource, demultiplexes the input stream, and accesses information 
about the format of the input data. 

• The Processor moves into the Configured state when it is connected to 
the DataSource and data format has been determined. When the 
Processor reaches the Configured state, a ConfigureCompleteEvent is 
posted. 

• When Real i ze is called, the Processor is transitioned to the Real i zed 
state. Once the Processor is Realized it is fully constructed. 

While a Processor is in the Configured state, getTrackControls can be 
called to get the TrackControl objects for the individual tracks in the 
media stream. These TrackControl objects enable you specify the media 
processing operations that you want the Processor to perform. 

Calling realize directly on an Unrealized Processor automatically transi- 
tions it through the Configuring and Configured states to the Realized state. 
When you do this, you cannot configure the processing options through 
the TrackControl s — the default Processor settings are used. 

Calls to the TrackControl methods once the Processor is in the Realized 
state will typically fail, though some Processor implementations might 
support them. 
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Methods Available in Each Processor State 
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&nce a Processor is a type of PI ayer, the restrictions on when methods can 
ta ; called 1 on a PI ayer also apply to Processors. Some of the Processor-spe- 
cific methods also are restricted to particular states. The following table 



shows the restrictions that apply to a Processor. If y OU call a method that 
is illegal m the current state, the Processor throws an error or exception. 



Method 



Unrealized 
Processor 



Configuring 
Processor 



Configured 
Processor 



Realized 
Processor 



addController 


Not Realized Error 


NotRealizedError 


NotReal i zedError 


legal 


deallocate 


legal 


legal 


legal 


legal 


getCont rol Panel Component 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


getControls 


legal 


legal 


legal 


legal 


getOataOutput 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


getCainControl 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


getOutputContentDescri ptor 


NotConfi gu redError 


NotConfi gu redError 


legal 


legal 


getSt art Latency 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


getSupportedCbntent- 
Oescriptors 


legal 


legal 


legal 


legal 



getTimeBase 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


getTrackControls 


NotConfi gu redError 


NotConfi gu redError 


legal 


FormatChange- 
Exception 


getVi sual Component 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


mapToTimeBase 


ClockStoppedExcepti on 


CI ockStoppedExcepti on 


CI ockStoppedExcepti on 


CI ockStopped- 
Excepti on 


realize 


legal 


legal 


legal 


legal 


removeControll er 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


setOutputContentDescriptor 


NotConfi gu redError 


NotConfi guredError 


legal 


FormatChange- 
Exception 


setMediaTime 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


setRate 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


setStopTime 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


setTi meBase 


NotRealizedError 


NotRealizedError 


NotRealizedError 


legal 


syncStart 


NotPrefetchedError 


NotPrefetchedError 


NotPrefetchedError 


NotPrefetchedError 



Table 2-2: Method restrictions for processors. 
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Processing Controls 

^ COn ?l what Pressing operations the Processor performs on a 
track through the TrackControl for that track. You call Processor 

K^a^ 0b *«* ^allofthetracksin 

Though a TrackControl, you can explicitly select the Effect, Codec, and 
Renderer pug-ins you want to use for the track. To find out what options 

To control the transcoding thaf s performed on a track by a particular 
Codec, you can get the Controls associated with the track by calline the 
TrackControl getControls method. This method returns the codec con- 
trols available for the track, such as BitRateControl and QualityControT 

Ss^onpag^ mf™ ab ° Ut ** ^ C ° ntr0lS dCfined by1MF ' 866 " Con - 

tf you know the output data format that you want, you can use the set- 
Format method to specify the Format and let the Processor choose an 
appropriate codec and renderer. Alternatively, you can specify the output 
format when the Processor is created by using a Processor-Model A Pro- 
cessorModel defines the input and output requirements for a Processor 
When a ProcessorModel is passed to the appropriate Manager create 
method the Manager does its best to create a Processor that meets the 
specified requirements. 

Data Output 

The getDataOutput method returns a Processor object's output as a Data- 
Source. This DataSource can be used as the input to another PI ayer or Pro- 
cessor or as the input to a data sink. (For more information about data 
sinks, see "Media Data Storage and Transmission" on page 37.) 

A Processor object's output DataSource can be of any type: PushData- 
Source, PushBufferDataSource, Pull DataSource, or PullBufferDataSource. 
Not all Processor objects output data— a Processor can render the pro- 
cessed data instead of outputting the data to a DataSource. A Processor 
that renders the media data is essentially a configurable PI ayer 
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Capture 

Amultimedia capturing device can act as a source for multimedia data 
de ivery. For example, a microphone can capture raw audio input or a dig- 
ital video capture board might deliver digital video from a camera Such 
capture devices are abstracted as DataSources. For example, a device that 
provides nmely delivery of data can be represented as a PushDataSource 
Any type of DataSource can be used as a capture DataSource: PushData- ' 
Source, PushBufferDataSource, Pull DataSource, or Pull Buff erDataSource. 

Some devices deliver multiple data streams-for example, an audio/ 
video conferencing board might deliver both an audio and a video stream 
The corresponding DataSource can contain multiple SourceStreams that " 
map to the data streams provided by the device. 
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Media Data Storage and Transmission 

A DataSi nk is used to read media data from a DataSource and render the 
media to some destination— generally a destination other than a presenta- 
tion device. A particular DataSi nk might write data to a file, write data 
across the network, or function as an KIP broadcaster. (For more informa- 
tion about using a DataSi nk as an RTP broadcaster, see 'Transmitting RTF- 
Data With a Data Sink" on page 149.) 

Like Players, DataSi nk objects are constructed through the Manager using 
a DataSource. A DataSi nk can use a StreamWri terControl to provide addi- 
tional control over how data is written to a file. See "Writing Media Data 
to a File" on page 74 for more information about how DataSi nk objects are 
used. 



Storage Controls 

A DataSi nk posts a DataSi nkEvent to report on its status. A DataSi nkEvent 
can be posted with a reason code, or the DataSi nk can post one of the fol- 
lowing DataSi nkEvent subtypes: 

• DataSi nkErrorEvent, which indicates that an error occurred while the 
DataSi nk was writing data. 

• EndOfStreamEvent, which indicates that the entire stream has 
successfully been written. 



To respond to events posted by a DataSi nk, you implement the DataSi n- 
kListener interface. 



Extensibility 

You can extend JMF by implementing custom plug-ins, media handlers 
and data sources. ' 



Implementing Plug-Ins 

By implementing one of the JMF plug-in interfaces, you can directly access 
and manipulate the media data associated with a Processor: 

• Implementing the Demultiplexer interface enables you to control how 
individual tracks are extracted from a multiplexed media stream. 

• Implementing the Codec interface enables you to perform the 
processing required to decode compressed media data, convert media 
data from one format to another, and encode raw media data into a 
compressed format. 

• Implementing the Effect interface enables you to perform custom 
processing on die media data. 

• Implementing the Mul ti pi exer interface enables you to specify how 
individual tracks are combined to form a single interleaved output 
stream for a Processor. 

• Implementing the Renderer interface enables you to control how data 
is processed and rendered to an output device. 

Note: The JMF Plug-In API is part of the official JMF API, but JMF PI ayers 
and Processors are not required to support plug-ins. Plug-ins won't work 
with JMF 1.0-based Players and some Processor implementations might 
choose not to support them. The reference implementation of JMF 2.0 pro- 
vided by Sun Microsystems, Inc. and IBM Corporation fully supports the 
plug-in API. 

Custom Codec, Effect, and Renderer plug-ins are available to a Processor 
through the TrackControl interface. To make a plug-in available to a 
default Processor or a Processor created with a ProcessorModel, you need 
to register it with the PI uglnManager. Once you've registered your plug-in, 
it is included in the list of plug-ins returned by the PI uglnManager get- 
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Pl uglnLi st method and can be accessed by the Manager when it constructs 
a Processor object. 

Implementing MediaHandlers and DataSources 

If the JMF Plug-In API doesn't provide the degree of flexibility that you 
need, you can directly implement several of the key JMF interfaces: Con- 
troller, Player, Processor, DataSource, and DataSink. For example you 
might want to implement a high-performance PI ayer that is optimised to 
present a single media format or a Controller that manages a completely 
different type of time-based media. 3 

The Manager mechanism used to construct Player, Processor, DataSource, 
and DataSi nk objects enables custom implementations of these JMF inter- 
faces to be used seamlessly with JMF. When one of the create methods is 
called, the Manager uses a well-defined mechanism to locate and construct 
the requested object. Your custom class can be selected and constructed 
through this mechanism once you register a unique package prefix with 
the PackageManager and put your class in the appropriate place in the pre- 
defined package hierarchy. 
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MediaHandler Construction 

Players, Processors, and DataSi nks are all types of MediaHandlers— they 
all read data from a DataSource. A MediaHandler is always constructed for 
a particular DataSource, which can be either identified explicitly or with a 
MediaLocator. When one of the createMediaHandTer methods is called, 
Manager uses the content-type name obtained from the DataSource to find 
and create an appropriate MediaHandl er object. 
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Manager 



createDataSource 



createPlayer 
createRea li zed Player 



createProcessor 
createReal i zedProcessor 

createDataSink 



uses 



PackageManager 



getContentPref i xLi st 
getProtocol Pref i xLi st 



creates fc 



DataSource 



getContentName 



| MediaHandler 



extends 



2" 



creates. 



Player 



extends 



creates 



^ Processor ~[ 



creates „ 



DataSink 



creates . 



► MediaProxy 



extends 



creates , 



DataSinkProxy ] 



Figure 2-18: JMF media handlers. 

JMF also supports another type of Medi aHandl er, Medi aProxy. A Medi aProxy 
processes content from one DataSource to create another. Typically, a Medi - 
aProxy reads a text configuration file that contains all of the information 
needed to make a connection to a server and obtain media data. To create 
a PI ayer from a Medi aProxy, Manager: 

1. Constructs a DataSource for the protocol described by the Medi aLocator 

2. Uses the content-type of the DataSource to construct a MediaProxy to 
read the configuration file. 

3. Gets a new DataSource from the MediaProxy. 

4. Uses the content-type of the new DataSource to construct a PI ayer. 

The mechanism that Manager uses to locate and instantiate an appropriate 
Medi aHandl er f or a particular DataSou rce is basically the same for all types 
of Medi aHandl ers: 



Understanding JMF 



41 



• Using the list of installed content package-prefixes retrieved from 
PackageManager , Manager generates a search list of available 
MediaHandler classes. 

• Manager steps through each class in the search list until it finds a class 
named Handl er that can be constructed and to which it can attach the 
DataSource. 

When constructing Players and Processors, Manager generates the search 
list of available handler classes from the list of installed content package- 
prefixes and the content-type name of the DataSource. To search for Pi av- 
ers, Manager looks for classes of the form: 

<content package-prefix>.media. content. <content-type>. Handler 
To search for Processors, Manager looks for classes of the form: 

<content package-prefix> .media. processor . <content- typo. Handl er 

If the located Medi aHandl er is a Medi aProxy, Manager gets a new DataSource 
from the MediaProxy and repeats the search process. 

If no appropriate MediaHandler can be found, the search process is 
repeated, substituting unknown for the content-type name. The unknown 
content type is supported by generic PI ayers that are capable of handling 
a large variety of media types, often in a platform-dependent way. 

Because a DataSi nk renders the data it reads from its DataSource to an out- 
put destination, when a DataSi nk is created the destination must also be 
taken into account. When constructing DataSi nks, Manager uses the list of 
content package-prefixes and the protocol from the MediaLocator that 
identifies the destination. For each content package-prefix, Manager adds 
to the search list a class name of the form: 



•eContent package-pref ix>. medi a. datasink. protocol .Hand! 



er 



If the located MediaHandler is a DataSi nk, Manager instantiates it, sets its 
DataSource and Medi aLocator, and returns the resulting DataSi nk object. If 
the handler is a DataSi nkProxy, Manager retrieves the content type of the 
proxy and generates a list of DataSi nk classes that support the protocol of 
the destination Medi alocator and the content type returned by the proxy: 

<content package-prefix>. media. datasink. protocol .<content-type>.Handler 

The process continues until an appropriate DataSi nk is located or the Man- 
ager has iterated through all of the content package-prefixes. 
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DataSource Construction 

Manager uses the same mechanism to construct DataSources that it uses to 
construct Medi aHandlers, except that it generates the search list of Data- 
Source class names from the list of installed protocol package-prefixes. 

For each protocol package-prefix, Manager adds to the search list a class 
name of the form: 

protocol package-pref i x>. medi a . protocol . protocol > . DataSource 

Manager steps through each class in the list until it finds a DataSource that 
it can instantiate and to which it can attach the Medi aLocator. 



3 

Presenting Time-Based 
Media with JMF 



To present time-based media such as audio or video with JMF, you use a 
PI ayer. Playback can be controlled prograrnmatically, or you can display a 
control-panel component that enables the user to control playback interac- 
tively. If you have several media streams that you want to play, you need 
to use a separate PI ayer for each one. to play them in sync, you can use 
one of the PI ayer objects to control the operation of the others. 

A Processor is a special type of PI ayer that can provide control over how 
the media data is processed before it is presented. Whether you're using a 
basic Player or a more advanced Processor to present media content, you 
use the same methods to manage playback. For information about how to 
control what processing is performed by a Processor, see "Processing 
Time-Based Media with JMF" on page 71. 

The Medi aPlayer bean is a Java Bean that encapsulates a JMF player to pro- 
vide an easy way to present media from an applet or application. The 
MediaPlayer bean automatically constructs a new Player when a different 
media stream is selected, which makes it easier to play a series of media 
clips or allow the user to select which media clip to play. For information 
about using the MediaPlayer bean, see "Presenting Media with the Media- 
Player Bean" on page 66 



Controlling a Player 

To play a media stream, you need to construct a PI ayer for the stream, con- 
figure the PI ayer and prepare it to run, and then start the PI ayer to begin 
playback. 
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Creating a Player 

You create a Player indirectly through the media Manager. To display the 
Player, you get the Player object's components and add them to your 
applet's presentation space or application window. 

When you need to create a new PI ayer, you request it from the Manager by 
calling createPl ayer or createProcessor. The Manager uses the media URL 
or MediaLocator that you specify to create an appropriate Player. A URL 
can only be successfully constructed if the appropriate corresponding URL- 
StreamHandler is installed. Medi aLocator doesn't have this restriction. 

Blocking Until a Player is Realized 

Many of the methods that can be called on a PI ayer require the PI ayer to 
be in the Realized state. One way to guarantee that a PI ayer is Realized 
when you call these methods is to use the Manager createReal izedPl ayer 
method to construct the PI ayer. This method provides a convenient way 
to create and realize a PI ayer in a single step. When this method is called, 
it blocks until the PI ayer is Realized. Manager provides an equivalent cre- 
ateReal izeProcessor method for constructing a Realized Processor. 

Note: Be aware that blocking until a PI ayer or Processor is Realized can 
produce unsatisfactory results. For example, if createReal izedPlayer is 
called in an applet, Appl et . start and Appl et . stop will not be able to 
interrupt the construction process. 

Using a ProcessorModel to Create a Processor 

A Processor can also be created using a ProcessorModel . The Processor- 
Model defines the input and output requirements for the Processor and the 
Manager does its best to create a Processor that meets these requirements. 
To create a Processor using a ProcessorModel, you call the Manager. cre- 
ateReal izedProcessor method. Example 3-1 creates a Realized Processor 
that can produce IMA4-encoded stereo audio tracks with a 44.1 kHz sam- 
ple rate and a 16-bit sample size. 

Example 3-1: Constructing a Processor with a ProcessorModel. 
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Since the ProcessorModel does not specify a source URL in this example, 
Manager implicitly finds a capture device that can capture audio and then 
creates a Processor that can encode that into IMA4. 

Note that when you create a Realized Processor with a ProcessorModel you 
will not be able to specify processing options through the Processor 
objecf s TrackControl s. For more information about specifying processing 
options for a Processor, see "Processing Time-Based Media with JMF" on 
page 71. 

Displaying Media Interface Components 

A Player generally has two types of user interface components, a visual 
component and a control-panel component. Some Player implementa- 
tions can display additional components, such as volume controls and 
download-progress bars. 

Displaying a Visual Component 

A visual component is where a Player presents the visual representation 
of its media, if it has one. Even an audio PI ayer might have a visual com- 
ponent, such as a waveform display or animated character. 

To display a Player object's visual component, you: 

1. Get the component by calling getVi sual Component. 

2. Add it to the applet 7 s presentation space or application window. 

You can access the PI ayer object's display properties, such as its x and y 
coordinates, through its visual component. The layout of the Player com- 
ponents is controlled through the AWT layout manager. 

Displaying a Control Panel Component 

A PI ayer often has a control panel that allows the user to control the 
media presentation. For example, a PI ayer might be associated with a set 
of buttons to start, stop, and pause the media stream, and with a slider 
control to adjust the volume. 
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Every Player provides a default control panel. To display the default con- 
trol panel: 

1. Call getControl PanelComponent to get the Component. 

2. Add the returned Component to your applet's presentation space or ap- 
plication window. 

If you prefer to define a custom user-interface, you can implement custom 
GUI Components and call the appropriate Player methods in response to 
user actions. If you register the custom components as Control 1 erLi sten- 
ers, you can also update them when the state of the PI ayer changes. 

Displaying a Gain-Control Component 

PI ayer implementations that support audio gain adjustments implement 
theCainControl interface. CainControl provides methods for adjusting the 
audio volume, such as setLevel and setMute. To display a CainControl 
Component if the Player provides one, you: 

1. Call getGai nControl to get the Cai nCont rol from the PI ayer. If the 
Player returns null, it does not support the CainControl interface. 

2. Call getControl Component on the returned CainControl. 

3. Add the returned Component to your applet's presentation space or ap- 
plication window. 

Note that getControl s does not return a PI ayer object's Cai nControl . You 
can only access the CainControl by calling getGai nControl. 

Displaying Custom Control Components 

Many Players have other properties that can be managed by the user. For 
example, a video PI ayer might allow the user to adjust brightness and 
contrast, which are not managed through the PI ayer interface. You can 
find out what custom controls a Player supports by calling the getCon- 
trol s method. 



For example, you can call getControl s to determine if a PI ayer supports 
theCachingControl interface. 
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Example 3-2: Using getControl s to find out what Controls are supported. 
^^^^^^^^^^ 




Displaying a Download-Progress Component 

The Cachi ngControl interface is a special type of Control implemented by 
PI ayers that can report their download progress. A Cachi ngControl pro- 
vides a default progress-bar component that is automatically updated as 
the download progresses. To use the default progress bar in an applet: 

1. Implement the ControllerLi stener interface and listen for 
Cachi ngControl Events in controllerUpdate. 

2. The first time you receive a Cachi ngControl Event: 

a. Call getCachi ngControl on the event to get the caching control. 

b. Call getProgressBar on the Cachi ngControl to get the default 
progress bar component. 

c. Add the progress bar component to your applet's presentation 

space. 

3. Each time you receive a Cachi ngControl Event, check to see if the down- 
load is complete. When getContentProgress returns the same value as 
getCon tent Length, remove the progress bar. 

The PI ayer posts a Cachi ngControl Event whenever the progress bar needs 
to be updated. If you implement your own progress bar component, you 
can listen for this event and update the download progress whenever 
Cachi ngControl Event is posted. 



Setting the Playback Rate 

The Player objecf s rate determines how media time changes with respect 
to time-base time; it defines how many units a PI ayer object's media time 
advances for every unit of time-base time. The PI ayer object's rate can be 
thought of as a temporal scale factor. For example, a rate of 2.0 indicates 
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that media time passes twice as fast as the time-base time when the PI aver 
is started. 7 

In theory, a PI ayer object's rate could be set to any real number, with neg- 
ative rates mterpreted as playing the media in reverse. However, some 
media formats have dependencies between frames that make it impossi- 
ble or impractical to play them in reverse or at non-standard rates. 

To set the rate, you call setRate and pass in the temporal scale factor as a 
float value. When setRate is called, the method returns the rate that is 
actually set, even if it has not changed. PI ayers are only guaranteed to 
support a rate of 1.0. 



Setting the Start Position 

Setting a Player object's media time is equivalent to setting a read posi- 
tion within a media stream. For a media data source such as a file, the 
media time is bounded; the maximum media time is defined by the end of 
the media stream. 

To set the media time you call setMedi aTi me and pass in a Ti me object that 
represents the time you want to set. 



Frame Positioning 

Some PI ayers allow you to seek to a particular frame of a video. This 
enables you to easily set the start position to the beginning of particular 
frame without having to specify the exact media time that corresponds to 
that position. Players that support frame positioning implement the 
FramePosi tioni ngControl . 

To set the frame position, you call the FramePosi tioni ngControl seek 
method. When you seek to a frame, the PI ayer object's media time is set 
to the value that corresponds to the beginning of that frame and a Medi a- 
TimeSetEvent is posted. 

Some Players can convert between media times and frame positions. You 
can use the FramePosi tioni ngControl mapFrameToTime and mapTimeToFrame 
methods to access this information, if if s available. (PI ayers that support 
FramePosi tioni ngControl are not required to export this information.) 
Note that there is not a one-to-one correspondence between media times 
and frames —a frame has a duration, so several different media times 
might map to the same frame. (See "Getting the Media Time" on page 53 
for more information.) 
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Preparing to Start 

Most media Players cannot be started instantly. Before the Player can 
start, certain hardware and software conditions must be met. For example, 
if the PI ayer has never been started, it might be necessary to allocate buff- 
ers in memory to store the media data. Or, if the media data resides on a 
network device, the Player might have to establish a network connection 
before it can download the data. Even if the Player has been started 
before, the buffers might contain data that is not valid for the current 
media position. 



Realizing and Prefetching a Player 

JMF breaks the process of preparing a Pi ayer to start into two phases, 
Realizing and Prefetching. Realizing and Prefetching a PI ayer before you start 
it minimizes the time it takes the PI ayer to begin presenting media when 
start is called and helps create a highly-responsive interactive experience 
for the user. Implementing the Cont rol 1 erLi stener interface allows you to 
control when these operations occur. 

Note: Processor introduces a third phase to the preparation process called 
Configuring. During this phase, Processor options can be selected to con- 
trol how the Processor manipulates the media data. For more informa- 
tion, see "Selecting Track Processing Options" on page 72. 

You call real i ze to move the PI ayer into the Realizing state and begin the 
realization process. You call prefetch to move the PI ayer into the Prefetch- 
ing state and initiate the prefetching process. The real ize and prefetch 
methods are asynchronous and return immediately. When the PI ayer 
completes the requested operation, it posts a Real izeCompleteEvent or 
PrefetchCompleteEvent. "Player States" on page 26 describes the opera- 
tions mat a PI ayer performs in each of these states. 

A Player in the Prefetched state is prepared to start and its start-up latency 
cannot be further reduced. However, setting the media time through set- 
Medi aTime might return the PI ayer to the Realized state and increase its 
start-up latency. 

Keep in mind that a Prefetched PI ayer ties up system resources. Because 
some resources, such as sound cards, might only be usable by one pro- 
gram at a time, having a PI ayer in the Prefetched state might prevent other 
Players from starting. 
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Determining the Start Latency 

To determine how much time is required to start a PI ayer, you can call 
getStartLatency. For Players that have a variable start latency, the return 
value of getStartLatency represents the maximum possible start latency. 
For some media types, getStartLatency might return WTENCYJJNKNOWN. 

The start-up latency reported by getStartLatency might differ depending 
on the Player object's current state. For example, after a prefetch opera- 
tion, the value returned by getStartLatency is typically smaller. A Con- 
troll er that can be added to a PI ayer will return a useful value once it is 
Prefetched. (For more information, see "Using a Player to Synchronize 
Controllers" on page 57.) 

Starting and Stopping the Presentation 

The Clock and Player interfaces define the methods for starting and stop- 
ping presentation. 



Starting the Presentation 

You typically start the presentation of media data by calling start. The 
start method tells the PI ayer to begin presenting media data as soon as 
possible. If necessary, start prepares the PI ayer to start by performing the 
realize and prefetch operations. If start is called on a Started Player, the 
only effect is that a StartEvent is posted in acknowledgment of the 
method call. 

Clock defines a syncStart method that can be used for synchronization. 
See "Synchronizing Multiple Media Streams" on page 56 for more infor- 
mation. 

To start a PI ayer at a specific point in a media stream: 

1. Specify the point in the media stream at which you want to start by call- 
ing setMediaTime. 

2. Call start on the Player. 



Stopping the Presentation 

There are four situations in which the presentation will stop: 
• When the stop method is called 
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• When the specified stop time is reached 

• When there's no more media data to present 

• When the media data is being received too slowly for acceptable play- 
When a PI aver is stopped, its media time is frozen if the source of 

aTdT ™H h 18 ^P^-* 6 data ^ntinues to be sLLd 

and the media time continues to advance. 

When a Sfc^Player is restarted, if the media rime was frozen, presenta- 
tion resumes from the stop time. If media time could not be frozJn Xn 

£^ ay %TT T*' "^P** 1 ° f ^ Stream resumes playbadT 
begins with the newly-received data. r^ymx. 

To stop a Pl ayer immediately, you call the stop method. If you call stop on 
* Stopped PI ayer, the only effect is that a StopByRequestEvent is posted in 
acknowledgment of the method call. P 

Stopping the Presentation at a Specified Time 

You can call setStopTime to indicate when a Player should stop The 
PI ayer stops when its media time passes the specified stop time. If the 
Player object's rate is positive, the Player stops when the media time 
becomes greater than or equal to the stop time. If the PI ayer object's rate 
is negative, the Player stops when the media time becomes less than or 
equal to the stop time. The PI ayer stops immediately if its current media 
time is already beyond the specified stop time. 

For example assume that a PI ayer object's media time is 5.0 and setStop- 
Ti me is called to set the stop time to 6.0. If the PI aye r object's rate is posi- 
tive, media time is increasing and the Player will stop when the media 
time becomes greater than or equal to 6.0. However, if the PI ayer object's 
rate is negative, it is playing in reverse and the Player will stop immedi- 
ately because the media time is already beyond the stop time. (For more 
information about PI ayer rates, see "Setting the Playback Rate" on 
page 47.) 

You can always call setStopTime on a Stopped PI ayer. However, you can 
only set the stop time on a Started PI ayer if the stop time is not currently 
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set If the Started PI ayer already has a stop time, setStopTI me throws an 
error. 

You can call getStopTime to get the currently scheduled stop time. If the 
clock has no scheduled stop time, getStopTime returns Clock. RESET. To 
remove the stop time so that the Player continues until it reaches end-of- 
media, call setStopTi me(CI ock . RESET) . 



Releasing Player Resources 

The deallocate method tells a PI ayer to release any exclusive resources 
and minimize its use of non-exclusive resources. Although buffering and 
memory management requirements for Players are not specified, most 
PI ayers allocate buffers that are large by the standards of Java objects. A 
well-implemented Player releases as much internal memory as possible 
when deal locate is called. 

The deallocate method can only be called on a Stopped PI ayer. To avoid 
ClockStartedErrors, you should call stop before you call deallocate. 
Calling deallocate on a PI ayer in the Prefetching or Prefetched state returns 
it to the Realized state. If deallocate is called while the PI ayer is realizing, 
die Player posts a DeallocateEvent and returns to the Unrealized state. 
(Once a PI ayer has been realized, it can never return to the Unrealized 
state.) 

You generally call deal 1 ocate when the PI ayer is not being used. For 
example, an applet should call deal! ocate as part of its stop method. By 
calling deallocate, the program can maintain references to the Player, 
while freeing other resources for use by the system as a whole. (JMF does 
not prevent a Realized PI ayer that has formerly been Prefetched or Started 
from maintaining information that would allow it to be started up more 
quickly in the future.) 

When you are finished with a PI ayer (or any other Control 1 er) and are 
not going to use it anymore, you should call close. The close method 
indicates that the Control 1 er will no longer be used and can shut itself 
down. Calling close releases all of the resources that the Control! er was 
using and causes it to cease all activity. When a Control 1 er is closed, it 
posts a Control 1 erCl osedEvent. A closed Control 1 er cannot be reopened 
and invoking methods on a closed Control 1 er might generate errors. 
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Getting the Time-Base Time 

You can get a PI ayer object's current time-base time by getting the PI aver 
object's Ti meBase and calling getTime: S V 

myCurrentTBTime = playerl.getTi meBase (). getTime (); 

When a Player is running, you can get the time-base time that corre- 
sponds to a particular media time by calling mapToTimeBase. 



Getting the Duration of the Media Stream 

Since programs often need to know how long a particular media stream 
wiH run, all Controllers implement the Duration interface. This interface 
defines a smgle method, getDuration. The duration represents the length 
of time that a media object would run, if played at the default rate of 1.0 A 
media stream's duration is only accessible through a PI ayer. 

If the duration can't be determined when getDuration is called 
DURATION_UNKNOWN is returned. This can happen if the PI ayer has not yet 
reached a state where the duration of the media source is available At a 
later time, the duration might be available and a call to getDuration 
would return the duration value. If the media source does not have a 
defined duration, as in the case of a live broadcast, getDuration returns 
DURATTONJJNBOUNDED. 



Responding to Media Events 

Controller!.! stener is an asynchronous interface for handling events gen- 
erated by Control 1 er objects. Using the Control 1 erLi stener interface 
enables you to manage the timing of potentially time-consuming Player 
operations such as prefetching. 

Implementing the ControlIerListener Interface 

To implement the Controll erLi stener interface, you need to: 

1. Implement the Control! erLi stener interface in a class. 

2. Register that class as a listener by calling addControllerLi stener on the 
Control 1 er that you want to receive events from. 
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When a Control 1 er posts an event, it calls control 1 erUpdate on each rem 



tered listener. 



regis- 



Typically, cont roll erUpdate is implemented as a series of if-else state- 
ments. 

Example 3-3:Implementing control! erUpdate. 




This filters out the events that you are not interested in. If you have regis- 
tered as a listener with multiple Controllers, you also need to determine 
which Controller posted the event. Control! erEvents come "stamped" 
with a reference to their source that you can access by calling getSource. 

When you receive events from a Control 1 er, you might need to do some 
additional processing to ensure that the Controller is in the proper state 
before calling a control method. For example, before calling any of the 
methods that are restricted to Stopped Players, you should check the 
PI ayer objecf s target state by calling getTargetState. If start has been 
called, the Player is considered to be in the Started state, though it might 
be posting transition events as it prepares the PI ayer to present media. 

Some types of Cont rol 1 erEvents contain additional state information. For 
example, the StartEvent and StopEvent classes each define a method that 
allows you to retrieve the media time at which the event occurred. 

Using ControllerAdapter 

Cont roll erAdapter is a convenience class that implements ControllerLis- 
tener and can be easily extended to respond to particular Events. To 
implement the Control 1 erLi stener interface using ControllerAdapter, 
you need to: 

1. Subclass ControllerAdapter and override the event methods for the 
events that you're interested in. 

2. Register your Control 1 erAdapter class as a listener for a particular Con- 
troller by calling addControllerListener. 
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When a Control! er posts an event, it calls control 1 erUpdate on each regis- 
tered listener. Controller Adapter automatically dispatches the event to 
the appropriate event method, filtering out the events that you're not 
interested in. 7 

For example, the following code extends a ControllerAdapter with a JDK 
1.1 anonymous inner-class to create a self-contained Player that is auto- 
matically reset to the beginning of the media and deallocated when the 
PI ayer reaches the end of the media. 




If you register a single Control 1 erAdapter as a listener for multiple PI ay- 
ers, in your event method implementations you need to determine which 
PI ayer generated the event. You can call getSource to determine where a 
Control! erEvent originated. 



Synchronizing Multiple Media Streams 

To synchronize the playback of multiple media streams, you can synchro- 
nize the Players by associating them with the same TimeBase. To do this, 
you use the getTimeBase and setTimeBase methods defined by the Clock 
interface. For example, you could synchronize pi ayerl with pi ayer2 by 
setting pi ayerl to use player2 * s time base: 

playerl.setTimeBase(player2.getTimeBaseO) ; 

When you synchronize Players by associating them with the same Time- 
Base, you must still manage the control of each PI ayer individually. 
Because managing synchronized PI ayers in this way can be complicated, 
JMF provides a mechanism that allows a PI ayer to assume control over ' 
any other Control 1 er. The PI ayer manages the states of these Control 1 ers 
automatically, allowing you to interact with the entire group through a 
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single point of control. For more information, see See "Using a Player to 
Synchronize Controllers". h y 
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Using a Player to Synchronize Controllers 

Synchronizing PI ayers directly using syncStart requires that you care- 
fuUy manage the states of all of the synchronized Players. You must con- 
trol each one individually, listening for events and calling control methods 
on them as appropriate. Even with only a few Players, this quickly 
becomes a difficult task. Through the Player interface, JMF provides a 
simpler solution: a PI ayer can be used to manage the operation of any 
Controller. J 

When you interact with a managing PI ayer, your instructions are auto- 
matically passed along to the managed Control 1 ers as appropriate The 
managing PI ayer takes care of the state management and synchronization 
tor all of the other Con t roll er s. 

This mechanism is implemented through the addController and remove- 
Controller methods. When you call addController on a Player, the Con- 
troller you specify is added to the list of Controllers managed by the 
Player. Conversely, when you call removeCont roller, the specified Con- 
trol! e r is removed from the list of managed Control 1 ers. 

Typically, when you need to synchronize PI ayers or other Control 1 ers 
you should use this addController mechanism. It is simpler, faster, and' 
less error-prone than attempting to manage synchronized Players'indi- 
vidually. 

When a Player assumes control of a Controller: 

• The Control 1 er assumes the PI ayer object's time base. 

• The Player object's duration becomes the longer of the Controller 
objecf s duration and its own. If multiple Controllers are placed un- 
der a Player object's control, the PI ayer object's duration is set to 
longest duration. 

• The Player object's start latency becomes the longer of the Controller 
objecf s start latency and its own. If multiple Control 1 ers are placed 
under a PI ayer object's control, the PI ayer object's start latency is set 
to the longest latency. 

A managing Player only posts completion events for asynchronous meth- 
ods after each of its managed Control 1 ers have posted the event. The 
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managing Player reposts other events generated by the Controllers as 
appropriate. } sas 

Aiding a Controller 

You use the addController method to add a Controller to the list of Con- 
trol 1 e rs managed by a particular PI ayer. To be added, a Control 1 er must 
be in the Realized state; otherwise, a NotRealizedError is thrown Two 
PI ayers cannot be placed under control of each other. For example if 
pl ayerl is placed under the control of pi ayer2, pi ayer2 cannot be placed 
under the control of pi ayerl without first removing playerl from 
player2's control. 

Once a Control 1 er has been added to a PI ayer, do not call methods 
directly on the managed Controller. To control a managed Controller 
you interact with the managing PI ayer. 

To have player2 assume control of playerl, call: 
player2. addController (playerl) ; 

Controlling Managed Controllers 

To control the operation of a group of Control 1 ers managed by a particu- 
lar Player, you interact directly with the managing Player. 

For example, to prepare all of the managed Controllers to start, call 
prefetch on the managing Player. Similarly, when you want to start them, 
call start on the managing Player. The managing Player makes sure that 
all of the Controllers are Prefetched, determines the maximum start 
latency among the Controllers, and calls syncStart to start them, specify- 
ing a time that takes the maximum start latency into account. 

When you call a Controller method on the managing Player, the Player 
propagates the method call to the managed Controllers as appropriate. 
Before calling a Controller method on a managed Controller, the Player 
ensures that the Controller is in the proper state. The following table 
describes what happens to the managed Control 1 ers when you call con- 
trol methods on the managing Player. 
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Function 



Stopped Player 



Started Player 



Invokes setMediaTime on all man- Stops all managed Controllers in- 
aged Controllers. vo kes setMediaTime, and restarts 

Controllers. 



setMediaTime 



setRate 



start 



realize 



prefetch 



stop 

deallocate 
setStopTime 

syncStart 
close 



Invokes setRate on all managed 
Controllers. Returns the actual 
rate that was supported by all Con- 
trol! ers and set. 



Stops all managed Controllers, in- 
vokes setRate, and restarts Control - 
lers. Returns the actual rate that 
was supported by all Controllers 
and set. 



Ensures all managed Control 1 ers Depends on the Player implementa- 

are Prefetched and invokes sync- tion. Player might immediately post 

Start on each of them, taking into a StartEvent. 
account their start latencies. 

The managing Player immediate- The managing Player immediately 



ly posts a Real izeCompl eteEvent 
To be added, a Control 1 er must 
already be realized. 

Invokes prefetch on all managed 
Controllers. 



No effect. 



Invokes deallocate on all man- 
aged Controllers. 

Invokes setStopTime on all man- 
aged Control 1 ers. (PI ayer must be 
Realized.) 

Invokes syncStart on all managed 
Controllers. 

Invokes close on all managed 
Controllers. 



posts a Real i zeCompl eteEvent. To be 
added, a Controller must already 
be realized. 

The managing Player immediately 
posts a PrefetchCompl eteEvent, in- 
dicating that all managed Control - 
lers are Prefetched. 

Invokes stop on all managed Con- 
trol! ers. 

It is illegal to call deal 1 ocate on a 
Started Player. 

Invokes setStopTi me on all managed 
Control! ers. (Can only be set once 
on a Started Player.) 

It is illegal to call syncStart on a 
Started Player. 

It is illegal to call close on a Started 
Player. 



Table 3-1: Calling control methods on a managing player. 



Removing a Controller 



You use the removeCont roller method to remove a Controller from the 
list of controllers managed by a particular PI ayer. 
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To have pi ayer2 release control of pi ayerl, call: 
pi aye r 2 . removeCont rol 1 e r (pi aye r 1) ; 

Synchronizing Players Directly 

In a few situations, you might want to manage the synchronization of 
multiple PI ayer objects yourself so that you can control the rates or media 
times independently. If you do this, you must: 

1. Register as a listener for each synchronized PI ayer. 

2. Determine which PI ayer object's time base is going to be used to drive 
the other Player objects and set the time base for the synchronized 
Player objects. Not all Player objects can assume a new time base. 
For example, if one of the PI ayer objects you want to synchronize has 
a push data-source, that Player object's time base must be used to 
drive the other Player objects. 

3. Set die rate for all of the PI ay e r s. If a PI aye r cannot support the rate you 
specify, it returns the rate that was used. (There is no mechanism for 
querying the rates that a Player supports.) 

4. Synchronize the states of all of the PI ayer objects. (For example, stop all 
of the players.) 

5. Synchronize the operation of the Player objects: 

• Set the media time for each PI ayer. 

• Prefetch each Player. 

• Determine the maximum start latency among the synchronized 
Player objects. 

• Start the Player objects by calling syncStart with a time that takes 
into account the maximum latency. 

You must listen for transition events for all of the PI ayer ob j ects and 
keep track of which ones have posted events. For example, when you 
prefetch the PI ayer objects, you need to keep track of which ones have 
posted Pref etchCompl ete events so that you can be sure all of them are 
Prefetched before calling syncStart. Similarly, when you request that the 
synchronized PI ayer objects stop at a particular time, you need to listen 
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for the stop event posted by each PI ayer to determine when all of them 
have actually stopped. 

In some situations, you need to be careful about responding to events 
posted by the synchronized PI ayer objects. To be sure of the state of all of 
the PI ayer objects, you might need to wait at certain stages for all of them 
to reach the same state before continuing. 

For example, assume that you are using one PI ayer to drive a group of 
synchronized PI ayer objects. A user interacting with that PI ayer sets the 
media time to 10, starts the PI ayer, and then changes the media time to 20. 
You then: 

1. Pass along the first setMedi aTi me call to all of the synchronized PI ayer 
objects. 

2. Call prefetch on each PI ayer to prepare them to start. 

3. Call stop on each PI ayer when the second set media time request is re- 
ceived. 

4. Call setMedi aTi me on each Player with the new time. 

5. Restart the prefetching operation. 

6. When all of the PI ayer objects have been prefetched, start them by call- 
ing syncStart, taking into account their start latencies. 

In this case, just listening for PrefetchComplete events from all of the 
PI ayer objects before calling syncStart isn't sufficient. You can't tell 
whether those events were posted in response to the first or second 
prefetch operation. To avoid this problem, you can block when you call 
stop and wait for all of the PI ayer objects to post stop events before con- 
tinuing. This guarantees that the next PrefetchComplete events you 
receive are the ones that you are really interested in. 

Example: Playing an MPEG Movie in an Applet 

The sample program PlayerAppl et demonstrates how to create a PI ayer 
and present an MPEG movie from within a Java applet. This is a general 
example that could easily be adapted to present other types of media 
streams. 
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The PI ayer object 7 s visual presentation and its controls are displayed 
within the applef s presentation space in the browser window. If you cre- 
ate a PI ayer in a Java application, you are responsible for creating the win- 
dow to display the PI ayer object's components. 

Note: While PlayerApplet illustrates the basic usage of a Player, it does 
not perform the error handling necessary in a real applet or application. 
For a more complete sample suitable for use as a template, see "JMF 
Applet" on page 173. 

Overview of PlayerApplet 

The APPLET tag is used to invoke PI ayerAppl et in an HTML file. The WIDTH 
and HEIGHT fields of the HTML APPLET tag determine the dimensions of the 
applet's presentation space in the browser window. The PARAM tag identi- 
fies the media file to be played. 



Example 3-5: Invoking PI ayerAppl et. 




When a user opens a web page containing PI ayerAppl et, the applet loads 
automatically and runs in the specified presentation space, which contains 
the PI ayer object's visual component and default controls. The PI ayer 
starts and plays the MPEG movie once. The user can use the default 
PI ayer controls to stop, restart, or replay the movie. If the page containing 
the applet is closed while the PI ayer is playing the movie, the PI ayer auto- 
matically stops and frees the resources it was using. 

To accomplish this, PI ayerAppl et extends Appl et and implements the Con- 
trollerListener interface. PlayerApplet defines five methods: 

• i ni t — creates a Pi ay e r for the file that was passed in through the PARAM 
tag and registers PI ayerAppl et as a controller listener so that it can ob- 
serve media events posted by the PI ayer. (This causes the PI ayerAp- 
pl et cont rol 1 er Update method to be called whenever the PI ayer posts 
an event) 

• start — starts the PI ayer when PI ayerAppl et is started. 

• stop — stops and deallocates die PI ayer when PI ayerAppl et is 
stopped. 

• destroy — closes the PI ayer when PI ayerAppl et is removed. 
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• control 1 erUpdate— responds to PI ayer events to display the PI ayer 
object's components. 

Example 3-6: PI ayerAppl et. 
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Initializing the Applet 

When a Java applet starts, its i rri t method is invoked automatically. You 
override i ni t to prepare your applet to be started. PI ayerAppl et performs 
four tasks in init: 

1 . Retrieves the applet's FILE parameter. 

2. Uses the FILE parameter to locate the media file and build a URL object 
that describes that media file. 

3. Creates a Player for the media file by calling Manager.createPlayer. 

4. Registers the applet as a controller listener with the new PI ayer by call- 
ing addControHerListener. Registering as a listener causes the Player- 
Applet controller-Update method to be called automatically whenever 
the PI ayer posts a media event. The PI ayer posts media events when- 
ever its state changes. This mechanism allows you to control the PI ayer 
objecf s transitions between states and ensure that the Player is in a 
state in which it can process your requests. (For more information, see 
"Player States" on page 26.) 



Example 3-7: Ihitializdng PI ayerApplet. 
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Controlling the Player 

The Applet class defines start and stop methods that are called automati- 
cally when the page containing the applet is opened and closed. You over- 
ride these methods to define what happens each time your applet starts 
and stops. 

PI ayerAppl et implements start to start the Pi ayer whenever the applet is 
started. 



Example 3-8: Starting the Player in PI ayerAppl et. 




Similarly PI ayer Applet overrides stop to stop and deallocate the Player: 
Example 3-9: Stopping the Player in PI ayerAppl et. 




Deallocating the PI ayer releases any resources mat would prevent another 
PI ayer from being started. For example, if the PI ayer uses a hardware 
device to present its media, deallocate frees that device so that other 
Players can use it. 

When an applet exits, destroy is called to dispose of any resources created 
by the applet. PI ayerAppl et overrides destroy to close the PI ayer. Closing 
a PI ayer releases all of the resources that if s using and shuts it down per- 
manently. 

Example 3-10: Destroying the Player in PI ayerAppl et. 
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Responding to Media Events 

PI ayerAppl et registers itself as a Control 1 erLi stener in its i ni t method so 
that it receives media events from the PI ayer. To respond to these events, 
PI ayerAppl et implements the control! erUpdate method, which is called' 
automatically when the Player posts an event. 

PI ayerAppl et responds to one type of event, Real i zeCorapl eteEvent. When 
the PI ayer posts a Real i zeCompl eteEvent, PI ayerAppl et displays the 
Player object's components. 



Example 3-11: Responding to media events in PI ayerAppl et. 




A PI ayer objecf s user-interface components cannot be displayed until the 
Player is Realized; an Unrealized Player doesn't know enough about its 
media stream to provide access to its user-interface components. PI ayer- 
Appl et waits for the PI ayer to post a Real i zeCompl eteEvent and then dis- 
plays the PI ayer object's visual component and default control panel by 
adding them to the applet container. Calling validate triggers the layout 
manager to update the display to include the new components. 

Presenting Media with the MediaPlayer Bean 

Using the Medi aPl aye r Java Bean (javax . medi a . bean . pi aye rbean . Medi a- 
Player) is the simplest way to present media streams in your applets and 
applications. MediaPlayer encapsulates a full-featured JMF Player in a 
Java Bean. You can either use the Medi aPl ayer bean's default controls or 
customize its control Components. 

One key advantage to using the Medi aPlayer bean is that it automatically 
constructs a new Player when a different media stream is selected for 
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Working with Real-Time 

Media Streams 



To send or receive a live media broadcast or conduct a video conference 
over the Internet or Intranet, you need to be able to receive and transmit 
media streams in real-time. This chapter introduces streaming media con- 
cepts and describes the Real-time Transport Protocol JMF uses for receiv- 
ing and transmitting media streams across the network. 

Streaming Media 

When media content is streamed to a client in real-time, the client can 
begin to play the stream without having to wait for the complete stream to 
download. In fact, the stream might not even have a predefined dura- 
tion—downloading the entire stream before playing it would be impossi- 
ble. The term streaming media is often used to refer to both this technique of 
delivering content over the network in real-time and the real-time media 
content thaf s delivered. 

Streaming media is everywhere you look on the web— live radio and tele- 
vision broadcasts and webcast concerts and events are being offered by a 
rapidly growing number of web portals, and if s now possible to conduct 
audio and video conferences over the Internet. By enabling the delivery of 
dynamic, interactive media content across the network, streaming media 
is changing the way people communicate and access information. 

Protocols for Streaming Media 

Transmitting media data across the net in real-time requires high network 
throughput. If s easier to compensate for lost data than to compensate for 
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large delays in receiving the data. This is very different from accessing 
static data such as a file, where the most important thing is that all of the 
data arrive at its destination. Consequently the protocols used for static 
data don't work well for streaming media. 

The HTTP and FTP protocols are based on the Transmission Control Pro- 
tocol (TCP). TCP is a transport-layer protocol 1 designed for reliable data 
communications on low-bandwidth, high-error-rate networks. When a 
packet is lost or corrupted, if s retransmitted. The overhead of guarantee- 
ing reliable data transfer slows the overall transmission rate. 

For this reason, underlying protocols other than TCP are typically used for 
streaming media. One that's commonly used is the User Datagram Proto- 
col (UDP). UDP is an unreliable protocol; it does not guarantee that each 
packet will reach its destination. There's also no guarantee that the pack- 
ets will arrive in the order that they were sent. The receiver has to be able 
to compensate for lost data, duplicate packets, and packets that arrive out 
of order. 

Like TCP, UDP is a general transport-layer protocol— a lower-level net- 
working protocol on top of which more application-specific protocols are 
built. The Internet standard for transporting real-time data such as audio 
and video is the Real-Time Transport Protocol (RTP). 

RTP is defined in IETF RFC 1889, a product of the AVT working group of 
the Internet Engineering Task Force (IETF). 



Real-Time Transport Protocol 

RTP provides end-to-end network delivery services for the transmission 
of real-time data. RTP is network and transport-protocol independent, 
though it is often used over UDP. 



In the seven layer BO/ OSI data communications model, the transport layer is level 
four. For more information about the ISO /OSI model, see Understanding OSI. 
Larmouth, John. International Thompson Computer Press, 1996. ISBN 1850321760. 
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Figure 7-1: KTP architecture. 



RIP can be used over both unicast and multicast network services Over a 
untcast network service, separate copies of the data are sent from the 
source to each destination. Over a multicast network service, the data is 
sent from the source only once and the network is responsible for trans- 
mitting the data to multiple locations. Multicasting is more efficient for 
many multimedia applications, such as video conferences. The standard 
Internet Protocol (IP) supports multicasting. 



RTP Services 



KTP enables you to identify the type of data being transmitted, determine 
what order the packets of data should be presented in, and synchronize 
media streams from different sources. 

RTP data packets are not guaranteed to arrive in the order that they were 
sent— in fact, they're not guaranteed to arrive at all. It's up to the receiver 
to reconstruct the sender's packet sequence and detect lost packets using 
the information provided in the packet header. 

While RTP does not provide any mechanism to ensure timely delivery or 
provide other quality of service guarantees, it is augmented by a control 
protocol (RTCP) that enables you to monitor the quality of the data distri- 
bution. RTCP also provides control and identification mechanisms for 
RTP transmissions. 

If quality of service is essential for a particular application, RTP can be 
used over a resource reservation protocol that provides connection-ori- 
ented services. 
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RTP Architecture 

^ ^SrST* 3X1 "^tion a set of applications communicat- 

ing w,th RTP. A session is identified by a network address andT^aTof 

fRTS>5data° rt 18 ^ ^ "* *" 0th6r isu ^foV control 

PaSrin^f ^ 3 ^ maChine ' h ° St ' ° r USer P^Pating in the session. 
Participation m a session can consist of passive reception of data 
(receiver), active transmission of data (sender), or both. 

Each media type is transmitted in a different session. For example, if both 
audio and video are used in a conference, one session is used to transmit 
the audio data and a separate session is used to transmit the video data 
This enables participants to choose which media types they want to 
receive— for example, someone who has a low-bandwidth network con- 
nection might only want to receive the audio portion of a conference. 

Data Packets 

The media data for a session is transmitted as a series of packets. A series 
of data packets that originate from a particular source is referred to as an 
" s ^ m - Each RTP data packet in a stream contains two parts, a struc- 
tured header and the actual data (the packet's payloafi. 

BitO 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 16 7 8 9 0 1 2 3 4 S 6 7 8 9 0 31 
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Figure 7-2: RTP data-packet header format. 

The header of an RTP data packet contains: 

• The RTP version number (V): 2 bits. The version defined by the cur- 
rent specification is 2. 
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• Padding ,(P): 1 bit If the padding bit is set, there are one or more bytes 
at the end of the packet that are not part of the payload. The very laS 
byte in the packet indicates the number of bytef of padcW ThJ 
padding is used by some encryption algorithms. 

• Extension (X): 1 bit. If the extension bit is set, the fixed header is fol- 
lowed by one header extension. This extension mechanism enables 
implementations to add information to the RTP Header. 

• 2 fi C ^r it / X ^ b !?- ^ nUmber ° f ^ ide nnfiers that follow 
the fixed header If the CSRC count is zero, the synchronization source 
is the source of the payload. 

• Marker (M): 1 bit. A marker bit defined by the particular media 

profile. 

• Payload Type (FT): 7 bits. An index into a media profile table that 
describes the payload format. The payload mappings for audio and 
video are specified in RFC 1890. 

• Sequence Number 16 bits. A unique packet number that identifies 
this packef s position in the sequence of packets. The packet number 
is incremented by one for each packet sent 

• Timestamp: 32 bits. Reflects the sampling instant of the first byte in 
the payload. Several consecutive packets can have the same 
timestamp if they are logically generated at the same time— for 
example, if they are all part of the same video frame. 

• SSRC 32 bits. Identifies the synchronization source. If the CSRC count 
is zero, the payload source is the synchronization source. If the CSRC 
count is nonzero, the SSRC identifies the mixer. 

• CSRC: 32 bits each. Identifies the contributing sources for the payload. 
The number of contributing sources is indicated by the CSRC count 
field; mere can be up to 16 contributing sources. If there are multiple 
contributing sources, the payload is the mixed data from those 
sources. 
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Control Packets 

In addition to the media data for a session, control data (RTCP) packets 
are sent periodically to all of the participants in the session. RTCP packets 
can contain information about the quality of service for the session partic- 
ipants, information about the source of the media being transmitted on the 
data port, and statistics pertaining to the data that has been transmitted so 
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There are several types of RTCP packets: 

• Sender Report 

• Receiver Report 

• Source Description 

• Bye 

• Application-specific 

RTCP packets are "stackable" and are sent as a compound packet that con 
tarns at least two packets, a report packet and a souVce description pack2. 

All participants in a session send RTCP packets. A participant that has 
recently sent data packets issues a sender report The sender report (SR) 

t0 ? f nUmb f of P ackets «* ^ sent as well as formation 
that can be used to synchronize media streams from different sessions. 

Session participants periodically issue receiver reports for all of the sources 
from which they are receiving data packets. A receiver report (RR) con- 
tains information about the number of packets lost, the highest sequence 
number received, and a timestamp that can be used to estimate the round- 
tap delay between a sender and me receiver. 

The first packet in a compound RTCP packet has to be a report packet 
even if no data has been sent or received— in which case, an empty ' 
receiver report is sent. r 3 

All compound RTCP packets must include a source description (SDES) 
element that contains the canonical name (CNAME) that identifies the 
source. Additional information might be included in the source descrip- 
tion, such as the source's name, email address, phone number, geographic 
location, application name, or a message describing the current state of the 
source. 

When a source is no longer active, it sends an RTCP BYE packet The BYE 
notice can include the reason that the source is leaving the session. 

RTCP APP packets provide a mechanism for applications to define and 
send custom information via the RTP control port. 

RTP Applications 

RTP applications are often divided into those that need to be able to 
receive data from the network (RTP Clients) and those that need to be able 
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to transmit data across the network (RTP Servers). Some applications do 
at tne same time that they're receiving data from the network. 
Receiving Media Streams From the Network 

• S^f^fS? * Pp]iC!itio ™ need to * able to receive a media stream 
from an RTP session and render it on the console. 

• A telephone answering machine application needs to be able to 
receive a media stream from an RTP session and store it in a file. 

• An application Aat records a conversation or conference must be able 
to receive a media stream from an RTP session and both render it on 
the console and store it in a file. 

Transmitting Media Streams Across the Network 

RTP server applications transmit captured or stored media streams across 
the network. 

For example, in a conferencing application, a media stream might be cap- 
tured from a video camera and sent out on one or more RTP sessions The 
media streams might be encoded in multiple media formats and sent out 
on several RTP sessions for conferencing with heterogeneous receivers 
Multiparty conferencing could be implemented without IP multicast bv 
using multiple unicast RTP sessions. 



References 

The RTP specification is a product of the Audio Video Transport (AVT) 
working group of the Internet Engineering Task Force (IETF). For addi- 
tional information about the IETF, see http : //www. i etf . org. The AVT 
working group charter and proceedings are available at 
http://www.ietf.org/html.charters/avt-charter.html. 

IETF RFC 1889, RTP: A Transport Protocol for Real Time Applications 
Current revision: http://www.ietf .org. internet-drafts/draft-ietf- 
avt-rtp-new-04 . txt 
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Cmtrol FC U90: RTPPr0 J Ue fi ,rAudi0 and ™*° Conferences with Minimal 

Current revision: http : //www. i etf . org . i nternet-draf ts/draft-i etf - 
avt-profile-new-06.txt 

J^Z^^^ are undergoing revisions in preparation for advance- 
ment from Proposed Standard to Draft Standard and the URLs listed here 
aref or the Internet Drafts of the revisions available at the time 5j5w£ 

In addition to these RFCs, separate payload specification documents 
Z^S 01 ? P arbcular P a yloads are to be carried in RTP. For a list of all of 
the RTP-related specifications, see the AVT working group charter af 
http : //www . i etf . org/html . charters/avt-charter . html . 



Understanding the JMF 

RTP API 



JMF gables the playback and transmission of RTP streams through the 
APIs defined in the javax.media. rtp, javax.media. rtp. event, and 

"tttp 3 ' rt ?* P acka ^ JMF can be extended to support addi- 
tonal RTP-speofic formats and dynamic payloads through me standard 
JMF plug-m mechanism. 

^JHF^ pUant ^P^entations are not required to support the 
RTP APIs in javax.media. Ptp, javax.media. rtp.event, and 
javax. media, ptp. ptcp. The reference implementations of JMF provided bv 
Sun Microsystems, Inc. and IBM Corporation fully support these APIs. 

You can play incoming RTP streams, locally save them to a file, or both. 




D 

File 



Figure 8-1: RTP reception. 

For example, the RTP APIs could be used to implement a telephony appli- 
cation that answers calls and records messages like an answering machine. 

Similarly, you can use the RTP APIs to transmit captured or stored media 
streams across the network. Outgoing RTP streams can originate from a 
file or a capture device. The outgoing streams can also be played locally 
saved to a file, or both. 3 ' 
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Figured: RIP transmission. 

For example, you could implement a video conferencing application that 
captures hve audio and video and transmits it across thf neKSinJ a 
separate RIP session for each media type. network using a 

Snularly, you might record a conference for later broadcast or use a prere- 
corded audio stream as "hold music" in a conferencing application 

RTP Architecture 

Hie JMF RTP APIs are designed to work seamlessly with the capture pre- 
sentation, and processing capabilities of JMF. Players and processors are 
used to present and manipulate RTP media streams just like any other 
media content. You can transmit media streams that have been captured 
from a local capture device using a capture DataSource or that have been 

8 5E? t ng 3 ° ataSi nk ' Similari y' JMF can be extended to support 
additional RTP formats and payloads through the standard plug-in mech- 
anism. 0 
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Figure 8-3: High-level JMF RTP architecture. 
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Session Manager 

In JMF, a Sessi onManager is used to coordinate an RIP session The session 

ItlfTS* m Tr Ser ** State of Ae as viewed from the 

local partiapant. In effect, a session manager is a local representation^ J 
debuted entity, the RIP session. The session manager Lo h Jnlles me 
RTCP control channel, and supports RTCP for both senders and reavers. 

^t S « S i S1 ° nMa J na9er interfaCe defines methods * at enable an application 
ir^T S T » * remove WMdJ^eSi 

created by the application, and close the entire session. 

Session Statistics 

The session manager maintains statistics on all of the RTP and RTCP pack 
ets sent and received in the session. Statistics are tracked for the entire ses- 
sion on a per-stxeam basis. The session manager provides access to global 
reception and transmission statistics: 

• ClobalReceptionStats: Maintains global reception statistics for the 
session. 

• ClobalTransnissionStats: Maintains cumulative transmission statis- 
tics for all local senders. 

Statistics for a particular recipient or outgoing stream are available from 
the stream: 

• ReceptionStats: Maintains source reception statistics for an individu- 
al participant. 

• TransmissionStats: Maintains transmission statistics for an individual 
send stream. 



Session Participants 

The session manager keeps track of all of the participants in a session 
Each partiapant is represented by an instance of a class that implements 
the Participant interface. Sessi onManagers create a Participant when- 
ever an RTCP packet arrives that contains a source description (SDES) 
with a canonical name(CNAME) that has not been seen before in the session 
(or has timed-out since its last use). Participants can be passive (sending 
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XmsF** 8 ^ ° r aCtiVC (ak ° ""^ ° ne ° r more RTP d ata 

^Sn??^ T /0C8/ Aat re P resents me local client/server 

parhapant. A local participant indicates that it will begin sending TrTCP 
control messages or data and maintain state on mcomi^S SSol 
messages by starting a session. 6 ana control 

A participant can own more than one stream, each of which is identified 
by Ae synchronization source identifier (SSRC) used by the soux"e 



stream, 
Session Streams 



The SessionManager maintains an RTPStream object for each stream of RTP 
data packets m the session. There are two types of RTP streams: 

• Recei veSt ream represents a stream that's being received from a remote 
participant. 

• SendStream represents a stream of data coming from the Processor or 
mput DataSource that is being sent over the network. 

A Recei veStream is constructed automatically whenever the session man- 
ager detects a new source of RTP data. To create a new SendStream, you 
call the SessionManager createSendStream method. 

RTP Events 

Several RTP-specific events are defined in javax.media. rtp. event These 
events are used to report on the state of the RTP session and streams. 
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| RTPEvent ~] 



Figured: RTP events. 



-j ReceiveStreamEvent I 

A — 1 




-ISendStreamEvent I 



\ RemoteConisionEventl 




J SessionEvent 1 

i_^= — 



j Local Payl oadChangeEvent | 



- } Local Coll i s i onEvent | 
- f NewParticipantEvent | 



121 



To receive notification of RTP events, you implement the appropriate RTP 
listener and register it with the session manager: 

• SessionListener: Receives notification of changes in the state of the 
session. 
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• RemoteLi stener: Receives notification of events or RIP control mes 
sages received from a remote participant. 

Session Listener 

You ^PlementSesslonLi stener to receive notification about evens 
pa^CS ^ ^ " 3 Wh ° Ie ' "* - *« «*»*» »f "eT 

There are two types of session-wide events: 

• ^ tiCiPantEVent: MiCale8 3 neW P^Pant has joined the 

• ^alCbllisionEvent: Indicates that the participanf s synchronization 
source is already in use. n 

Send Stream Listener 

You can implement SendSt reamLi stener to receive notification whenever: 

• New send streams are created by the local participant. 

• The transfer of data from the DataSource used to create the send 
stream has started or stopped. 

• The send stream's format or payload changes. 

There are five types of events associated with a SendStream: 

• NewSendStreaaEvent: Indicates that a new send stream has been creat- 
ed by the local participant. 

• Acti veSendStreaaiEvent: Indicates that the transfer of data from the 
DataSou rce used to create the send stream has started. 

• InactiveSendStreamEvent: Indicates that the transfer of data from the 
DataSource used to create the send stream has stopped. 

• LocalPayloadChangeEvent: Indicates that the stream's format or pav- 
load has changed. 
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• StreamClosedEvent: Indicates that the stream has been closed. 
Receive Stream Listener 

You can implement Recei veStreanU stener to receive notification when- 

• New receive streams are created. 

• The transfer of data starts or stops. 

• The data transfer times out. 

• A previously orphaned Recei veStream has been associated with a Par- 
ticipant. 

• An RTCP APP packet is received. 

• The receive stream's format or payload changes. 

You can also use this interface to get a handle on the stream and access the 
DataSource so that you can create a Medi aHandler. 

There are seven types of events associated with a Recei veStream: 

• NewReceiveStreanEvent: Indicates that the session manager has creat- 
ed a new receive stream for a newly-detected source. 

• Acti veReceiveStreamEvent : Indicates that the transfer of data has 
started. 

• Inacti veReceiveStreamEvent: Indicates that the transfer of data has 
stopped. 

• TineoutEvent: Indicates that the data transfer has timed out. 

• RemotePayloadChangeEvent: Indicates that the format or payload of the 
receive stream has changed. 

• StreamMappedEvent: Indicates that a previously orphaned receive 
stream has been associated with a participant. 

• Appl icationEvent: Indicates that an RTCP APP packet has been 
received. 



Remote Listener 

You can implement RemoteLi stener to receive notification of events or 
RTP control messages received from a remote participants. You might 
want to implement RemoteLi stener in an application used to monitor the 
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Z 8 ^^ enaWeS y ° U *? reCeive RTCP re P orts monitor the quality of 
eachTt^ 

There are three types of events associated with a remote participant: 

# rtTved rReP ° rtEVent: IndiCateS ** 311 RTP receiver re P° rt been 

' ^d rRePOrtEVent: IndiCateS ** 311 RTP re P° rt *™ been re- 

• RemoteGoll isionEvent: Indicates that two remote participants are 
using the same synchronization source ID (SSRC). 

RTP Data 

The streams within an RTP session are represented by RTPSt ream objects 
There are two types of RTPStreams: Recei veStream and SendStrean,. Each' 
Kit stream has a buffer data source associated with it. For Recei veS- 
treams, this DataSource is always a PushBufferDataSource. 

The session manager automatically constructs new receive streams as it 
detects additional streams arriving from remote participants. You con- 
struct new send streams by calling createSendStream on the session man- 
ager. 



Data Handlers 



The JMF RTP APIs are designed to be transport-protocol independent A 
custom RTP data handler can be created to enable JMF to work over a spe- 
cific transport protocol. The data handler is a DataSource that can be used 
as the media source for a Player. 

The abstract class RTPPushDataSource defines the basic elements of a JMF 
RTP data handler. A data handler has both an input data stream (Push- 
Sou rceSt ream) and an output data stream (OuputDataStream). A data han- 
dler can be used for either the data channel or the control channel of an 
RTP session. If it is used for the data channel, the data handler implements 
the DataChannel interface. 

An RTPSocket is an RTPPushDataSource has both a data and control chan- 
nel. Each channel has an input and output stream to stream data to and 
from the underlying network. An RTPSocket can export RTPControl s to 
add dynamic payload information to the session manager. 
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US 

d? tosAen ^e and location for custom RTPSocketimpir 

protocol Package-prefix>.media.protocol.rtpraw.DataSource 
RTP Data Formats 

Z fTT^ da ? USeS 311 ^P"^ format encoding as defined in 
theAudnoFormat and VideoFormat classes. For example, gsm RTPencamu- 
lated packets have the encoding set to Audi oFormat .GSM RTP, whileS 
encoded video formats have the encoding set to VideoFormat . J PEG.RTP. 

AudioFormat defines four standard RTP-spedfic encoding strings: 

public static final String ULAW.RTP = " JAUDI0_C711_ULAW/rt D " • 
public static final String DVI_RTP = "dvi/rtp"; 
public static final String C723_RTP = "g72yrtv"- 
public static final String CSM_RTP = "gsrn/rtp"; 

Vi deoFormat defines three standard RTP-spedfic encoding strings: 

public static final String JPEG_RTP = "jpeg/rtp"; 
public static final String H260TP « "h261/rtp M ; 
public static final String H263_RTP = "h263/rtp"; 

RTP Controls 

The RTP API defines one RTP-spedfic control, RTPControl. RTPControl is 
typically implemented by RTP-specifjc DataSources. It provides a mecha- 
nism to add a mapping between a dynamic payload and a Format. RTPCon- 
trol also provides methods for accessing session statistics and getting the 
current payload Format. 

SessionManager also extends the Control s interface, enabling a session 
manager to export additional Controls through the getControl and get- 
Control s methods. For example, the session manager can export a Buffer- 
Control to enable you to specify the buffer length and threshold. 

Reception 

The presentation of an incoming RTP stream is handled by a PI ayer. To 
receive and present a single stream from an RTP session, you can use a 
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Medi aLocator that describes the session to construct a PI ayer. A media 
locator for an KIT session is of the form: 

rtp : / /address : po rt [ : ss re] /content- type/ [ ttl ] 
Hie Player is constructed and connected to the first stream in the session. 
If there are multiple streams in the session that you want to present vou 
need to use a session manager. You can receive notification from the 
sum manager whenever a stream is added to the session and construct 
P ayer for each new stream. Using a session manager also enables you to 
directly monitor and control the session. Y 

Transmission 

Asession manager can also be used to initialize and control a session so 
that you can stream data across the network. The data to be streamed is 
acquired from a Processor. 

For example, to create a send stream to transmit data from a live capture 
source, you would: ^ 

1. Create, initialize, and start a SessionManager for the session. 

2. Construct a Processor using the appropriate capture DataSource. 

3. Set the output format of the Processor to an RTP-spedfic format. An 
appropriate RTP packetizer codec must be available for the data format 
you want to transmit. 

4. Retrieve the output DataSource from the Processor. 

5. Call createSendStream on the session manager and pass in the Data- 
Source. 

You control the transmission through the SendStream start and stop 
methods. 

When it is first started, the SessionManager behaves as a receiver (sends 
out RTCF 'receiver reports). As soon as a SendStream is created, it begins to 
send out RTCP sender reports and behaves as a sender host as long as one 
or more send streams exist. If all SendSt reams are closed (not just stopped) 
the session manager reverts to being a passive receiver. ' 
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Extensibility 

e^d^ i^^' *" RTP ca P abai «es can be enhanced and 

A *T a ^ ^ ^ SUpP ° rt 3 basic of folm ^ and payloads 
Advanced developers and technology providers can implement^ 
plug-ins to support dynamic payloads and additional RTP formats. 

Implementing Custom Packetizers and Depacketizers 

implement a custom packetizer or depacketizer, you implement the 
JMF Codec interface. (For general information about JMF plug-ins see 
"Implementing JMF Plug-Ins" on page 85.) P g ' 866 
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9 

Receiving and Presenting 
RTP Media Streams 



JMF Players and Processors provide the presentation, capture, and data 
conversion mechanisms for RTP streams. P 




Network 




Figure 9-1: RTP reception data flow. 

A separate player is used for each stream received by the session manager 
You construct a Player for an RTP stream through the standard M TnTgef 
createPI ayer mechanism. You can either: 

• Use a Medi aLocator that has the parameters of the RTP session and 
construct a Player by calling Manager. createPI ayer (Medi aLocator) 

• Construct a PI ayer for a particular Recei veStream by retrieving the 
DataSource from the stream and passing it to Manager . createPI ay- 
er (DataSource). 

firST ^ Medi f u Lo " t J or to ®™*nict a PI ayer, you can only present the 

J? SOT 8 dCteCted in aesaoa ' U y° u want ^ Play back 
multiple RTP streams in a session, you need to use the SessionManager 
directly and construct a PI ayer for each Recei veStream. 
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Creating a Player for an RTP Session 

When you use a MediaLocator to construct a Player for an RTP session 
the Manager creates a PI ayer for the first stream detected^ the Son 
Thayer posts a Real W eteEvent onc€ data ^^Sdi 



frofcom^^ 



ateRealizedPlayer to construct a Player for an RTP^Ih^ ^k/ Cre_ 

tempting to create a Realized Player would block indefinitely 

ov^iT ^ ^ ° ne ^P"** «>ntrol RTPControl, which provides 

Se^ 



Example 9-1: Creating a Player for an RTP session (1 of 2) 

^^^^B^^BBSS^a& m »j«», j. .j ■ 





Listening for Format Changes 

^nlT POSt i 3 ForraatCha "9«*ven t, it might indicate that a payload 
change has occurred Players constructed with! MediaLocator automati 
caUyprocesspayload changes. In most cases, this processing invXTcon- 
~|L neW " «T to handIe me ™ format Applicants Z 
A^n^T media streams need to listen for FormatChangeEvents so that 
they can respond if a new PI ayer is created. 

When a FormatChangeEvent is posted, check whether or not the Player 
object's control and visual components have changed. If they have, a new 
Player has been constructed and you need to remove references to the old 
Player object's components and get the new PI ayer object's components. 

Exa ^ n !!? e !f j rc 17 fonnat changes (1 of 2) 
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Creating an RTP Player for Each New Receive Stream 

To play all of the ReceiveSt reams in a session, you need to create a sep< 
rate Player for each stream. When a new stream is created, the session 
manager posts a NewRecei veStreamEvent. Generally you register as a 
ReceiveStreamListener and construct a Player for each new ReceiveS- 
tream. To construct the Player, you retrieve the DataSource from the 
ReceiveSt ream and pass it to Manager . createPlayer. 

To create a PI ayer for each new receive stream in a session: 



1. Set up the RTP session: 

a. Create a SessionManager. For example, construct an instance of 
com.sun. media. rtp.RTPSessionMgr. (RTPSessionMgr is an imple- 
mentation of SessionManager provided with the JMF reference 
implementation.) 



Presenting RTPMedia Streams 

b. c^ KessimKgr addRecejveStreamLfstener toregjsterasa ^ 
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cei veStreamEvent, which indicates that a new data stream has been de- 
tected. 

3. When a NewRecei veStreamEvent is detected, retrieve the ReceiveStream 
from the NewReceiveStreamEvent by calling getReceiveStream. 

4. Retrieve the RTP DataSource from the ReceiveStream by calling get- 
DataSource. This is a PushBufferDataSource with an RTP-spedfic For- 
mat. For example, the encoding for a DVI audio player will be DVI_RTP. 

5. Pass the DataSource to Manager, create Player to constructa Player. For 
the PI ayer to be successfully constructed, the necessary plug-ins for de- 
coding and depacketizing the RTP-formatted data must be available. 
(For more information, see "Creating Custom Packetizers and Depack- 
etizers" on page 167). 



Receiving and Presenting RTP Media Streams 
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See RTPUti 1 in "RTPUtil" on page 223 for a complete example. 
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Chaplei I. WebSphere application! 



used to form applied and wh it h SS^f What are 
monitor applications. US6d t0 ed,t ' mana 9 e - de P'°V. run and 



1-1 What is an application? 



£££££ ^21°; ™ ebSphera te * «*~» - -»•«** 



1-2 What is a servlet? 



on Ihe server. Jus, ft e tea £££ atX r T" an wte '' ™» 
ad.an.aoe over app,e,s ^ FiTT V b ' B 

Servlels can men exercise a mi m ™ . . , 8,6 se ™«^ resources. 
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associated Casses and mSSS^l^S^^ 4 «* 
servers. Servlets can also use additional ^! T *" m ° St ma >° r Web 
extend the Java Servlet API 2. i C ' asses and P^teges to 

Servlets communicate through reauests anri «o«^ 
behavior of HyperText Transfer P^£™^ t * n?hr * fhe 
engine running on a Web server bZZfXZ' V mteraCt with a serv,ef 
example, when a c^a.nd.T^^S^'T ^ reSP ° nSes " For 
request information onto the 8erS a ^2 h J?.?^ ,he server send the 
form a response which 




^ ^'^^cornmunicationancl^raction 



^^^£ZZE^" «~- * *— I or they 
a servlet wiH continue ^ ^TS£^T ^ ^ '° aded ' 
^er.^ 

compile the »»nmcj^£^^^^ c,ass *«*• To 
compiles without any err^ and c^e^ » r ? USed " After the code 
these files into app^t^T^Tnl ^ ^ then We have to «W 
the class file, ^S^SSZ^S" ** JaVa ^ code * nd 
- d '° 9 °intheng^ 

2.1 Servlet lifecycle 



AppHcatton Server Section Guide Enterprise Edition: Getting Started 



handle requests from zero or more clients until wh*n thn 

servlet. nen the server removes the 

1.2.1.1 Initializing a servlet 

After the servlet is loaded into memory, the servlet enoine attorns ♦ 
an instance of the servlet This is usua lv rinnlZ I 9 , attem P ,s t0 ^eate 
that option is activated for the servte * at foe l? 6 ,.^"^ 0 " s ^up. if 
servlet after the application's s^up '° r ,he 

The servlet engine creates an instance by creating the servlet ^ 

an applicaton and its serv,e.s to be JS^'iST^Sr 
the application and servlets will be unable to be run i 0886 
changes their status to available. me adm,n,strat °'- 

1.2.1.2 Handling client requests 

The service method gets information about the reauest from th«, « 
1.2.1.3 Destroying a servlet 
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1.2.2 Java Servlet API V2.1 overview 

flXdX^^ ,nterfaCe (AP,) has bee " Signed 

P^e^^S T* expend is 

1. An HTTP-specific package 

2. A non-HTTP-specific package 

implements the Jara ServS API V2 1 £ IZ^, ^ *"*" 

• javax. servlet 

• javax.servlet.http 

Ixceotons MoS^f C ° n ! ain S6Ven interfaces « ,ive c,as «* and two 

1.2.3 IBM extensions to the Servlet API V2.1 

T ate 11 6asier 10 mana 9e session states and to create 

V2. 1 . The additional packages and classes are: 
- c °^-webspher e .ser^^ packgge 

• co">'bm.websphere.servlet.p e rsonali 2 ation.userprofile package 

• com.ibm.websphere.db package 

• com.ibm.websphere.servlet.error.ServletErrorReport class 

• com.ibm.websphere.servlet.event package 

• com.ibm.websphere.servlet.filter package 

• com.ibm.websphere.servlet.request package 

• com.ibm.websphere.servlet.response package 
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1.2.4 Servlet API V2.1 details 

This section describes the functions of the Java Servlet API v? i « „ 
the IBM extensions to the API. 2 " 1 as we " as 

As listed in 1.2.3, 'IBM extensions to the Servlet API v?i» n „ n A u 

«^.lbn,.w^ph. re .„ n , l „. p ^. IIM|OMTO|o ^ ck|nBp<<!i((i9e 

This package provides the following: 

• Records the referral page that ied the visitor to your Web site. 

• Tracks the visitor's position within the site. 

• Associates user identification with the session. 
com.lbm.websphe re .^^ 

This package provides the following- 

com.lbm.websphere.db package 

This package provides the following: 
• Simplifies access to relational databases 

com.lbni.web,ph 8re . Mrv | e ,. errofServ|etErrorRepor( ^ 

255: : n h ~rr on ,o — *— - 

com.lbm.websphere.servletevent package 

This package provides the following: 
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An interface for registering listeners. 



com.ibm.websphere.servlet.fllter package 

This package provides the following: 

• Support for sen/let chaining. 

' Z£X%£?£2r* ■"»«—« ~„ to „ 

• The ServletChain object. 

• The ChainResponse object. 

com.lbm.websphere.servlet.request package 

This package provides the following: 

• The HttpServletRequestProxy abstract class is used to overload the 
servlet eng.ne's HttpServletRequest object, causing \v£Z£££ 
request object to be forwarded to another servlet tor peeling 

• The ServletlnputStreamAdapter class is used to convert an mounts 

Z*%T nputstream and proxyin * a " — 3T 

com.ibm.websphere.servletresponse package 

This package provides the following: 

" ™*"y Se rtf tR e s P°»seP™y abstract class is used to overload the 
■en** engine's HttpServletResponse object, causing I Ite^SSSI? 
response object to be forwarded to another servlet for piocetlg 

" ^lff^ /e ^ t/ ' Sfrea ^^r class is used to convert an 

Kdl^ 

1.2.5 Changes to packages supported in WAS V2 
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»>e connection ISSSKEJ «""*» ^ *"« * «* 

««oin ft. Appiica,™ Sen*, Ve,*on 3 the Mowing pack^ tave 

• comibm.servlet.personalization.sam 

• com.ibm.serv/et.servlets.personalization.util 

1.3 What are Enterprise Java beans (EJB)? " ~ 

3.1 Introduction 

JavaBeans specifications which can be found at mstnier P«se 

http: //java.sun.conv'procilucts/ejb/docs.htna 

ron e paTer Cate9 ° n ' eS ° ,enterpriSe beanS " The ' are sh ™ Figure 
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Figure 2. Categories of enterprise beans 
1.3.1.1 Entity beans 

. ° ,her hand when the container Indies the data 
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Stepl 

Container creah 
an instance of the 
Ertffybean. 




Step2 

Container Invokes the setBnftjContexl 



Step3 

Aft« creation. tt« enttybean iwtanoe 
fc pUottd tn a pool Contain* ©an 
■wok. any of the bear* finder 
methods. 



CONT/MNER 





JStep^aXNewEnti* 
XfentoaboniatBOfrwftod 
•andft. container cafc jbCreateO X 

.•Step 4(b): Betting EnO* N 
■CBtrt] : ojIi find* mettod and tie 
Joontofcw oalb «JbActkateO. 
£tep3: 

£onatinef oan oil eJbLoadO & efcStor^n (a 0: 
-rj*chro«w tie errt3y dWai*h dateoSii J*™?^ caO me e^Passi***) 
" to return tie bean to the Poo* Start* 



I Step7 v— 

• nwfiod, tt*«ntt)rki removed \ 

• PennanemVfrom tie 

, uwctEr*ft»Conte>dO on an «r*v 
I "L? Pooted 9^ to remove 
' instance. 



■ONTVQINER 




Ffcuraa Entity bean life cycle 

Each entity bean consists of the following 4 components: 

a ' thfl! C ' aSS: Th,S C,3SS iS im P lemen *ed by the developer to encaosulate 
the b Us .ness methods and data. This Cass is hidden' rorn the l n t 
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b. 



c. 



con^ner CeSSed * ** ^ 'Rented by the 

T? ^ S ' nCe bean inste ™ s »™ "nioue (his class 
encapsulates one or more rartables and methods to manioutate aZL 
= , wnlch are used as a „ lm ary * to „„,, ° ^nCa S 

1.3.1.2 Session beans 

Session beans encapsulate non-permanent date Th*» 

persistent by using underlying entity beans. * data 

Every session bean has the following three components: 

• Bean class 

• Home interface 

• Remote interface 

sem,-permanent data, then their instances become unique " 
across the methods and is shortSST ° 6S ma,nWn data 
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Step 2 

Contoiw envdces t»«*«tS«wionCookxt 




Step3 

Cfent invokes 
business method 




cfar* invoke* j m«thod on' 
passtoted bun, the oonUnaf 

n goes bade to the ready; 




Step7 

Wh«n the ciwrtor ti« contan«f 

c « & •jbRtmoveO nwthod. thesatsion 
bttarfe oycteends. 



Figure 4. Session bean life cycle 
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1.3.2 EJB architecture in brief 



1. EJB server 



?h^ P 6 Sh !P S With 0n,y one EJB the EjZZwfig 

Str de » an deta,,ed informa «°" °n EJB sen/ere in Writing 
" WebSpheFe ' SC09 - 4431 - 01 . that ships 

This book can also be viewed or downloaded from: 

http: //ww*. ita- ccm/aof twarB/websezvers/afpserv/library.html 

2. Data source 

L h u^ 6 l? c ltl in en,, '!r bMnS is Stored in a arable date 
source. For container managed persistence (CMP) the EJB server 

supports IBM DB2, Oracle, and Microsoft SQL Served and fhe 3 itZr 
(CB) supports DB2, Oracle, IBM CICS and IBM ImT ^ 

r^^r," 13 ? 9 ^ persistence (BMP), the user can use any data source 
3. EJB clients 
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The EJB clients can be one or more of the following: Java servlet Java 
applet-servlet combination, or a JSP file. A Java apjlet can be7sed ^h a 
servlet to mteract with the enterprise beans, while Z th Tiil se^rTcm 
a Java applet can directly interact with the Enterprise Javan befns In an 

^r a ufL e ::z m r r tionai ejb c,ients sees 

n52k \? ? ^ d Java cl,ents ' and 10 a limit "* degree a C++ 
bv t^tir T M °Z d6tai,S ° n h0W 10 wri,e EJB cl ™* can be obtained 
SCOS M43? o'l 9 EnterPn$e BeanS Webs P h *'* 

4. Administration interface 

ITJJLTZV^ US6S the WebS P h ere Administrative Console to 
adm.n.ster the EJB server. The EJB server (CB) uses the System 
Management End User Interface (SMEUI) 




5. E/8 environment and interaction with other components 



What are JavaServer Pages (JSP) 



JavaServer Pages (JSP) technology provides developers with an easv and 

generate HTML "SSSS VI "? ^ JS * 

generate HTML, extensible Markup Language (XML), and other structured 
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1.4.1 JSP process flow 

The JSP process flow is shown in Figure 6 on page 15. 
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When WebSphere is installed on top of a Web server, the Web server's 
conf.gurat.on ,s modified to pass the HTTP requests for the JSP files to the 
WebSphere application server. WebSphere then passes this request to the 

whlch is ^9 but a Java servlet which compites the JSPfile 
whth f„ 'J"* Creat6S ,HeS for each JSP file - » creates a .java We 

/ »i ^ C °? e f ° r the SerVtet ' and 3 c,ass ,i,e - which * a c^mpned 
bytecode for the .java file. The JSP Processor for JSP 0.91 is the 

com.ibm.servlet.jsp.http.pagecompile.PageCompileServlet 
and for JSP 1.0 it is the 

com.sun.jsp.runtimeJspServlet 
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\w!h<fnhf f A eS T S Puts ,he and fne class «'es inside the 

o^wh^ PPSe ^^ Temp f0lder The ,ocalfon °» files will depend 
on whether you are using JSP 0.91 or JSP 1 .0 in your application. 

For example, if you are using JSP 0.91 and the JSP file is in the following 

^* S " 0 ^^ th *n the JSP processor will 

place the .java and the .class files in the following path: processor Wl " 

<WASRoot>\temp\examples\pagecompile folder. 

til 6 i? P processor uses a racing convention to name these iava anri 

oLt«S "* f ° r eXamp,e ' lhe JSP fi,ena ™ * simple,",^ ^Z7e 
processor will name the .java and the .class files as simp e x so ^ava «nd 
_s.mp.e_xisp.Cass. respectively. Under JSP 0.91 the". ja^ f^aivTys kept. 
If you are using JSP 1.0 and the JSP file is in the following folder: 

<WASRoot>\hosts\default_host\examples\web, then the JSP processor will 
place the .class files in the following path: Processor will 

<WASRoot>\temp\examples 

L« J n P 1 '° processor names Cass file simple.class and by default the 

seUhe !n« Pa r^V^ T ° ^ the J~ < i,e » *™~£l> 

rln H k P 8me kee ra enera «^ used by the JspServlet to true You 
cando this^rom the WebSphere Administrative console as shown^r e 7 
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3/21/00 5:33 PH : Loading ... 
3/21/00 5:33 PH : Console Ready. 



Figure 7. Setting Init Parm Name for JspServtet 



The Java and the .class files generated from the JSP file are servlets 
extending the javax.servlet.http.HttpServlet class. A sample JSP 0.91 file and 
the Java code generated by it is shown in Figure 8 on page 18. 

<BEBN name= n sinpleSessianMsg B type="SinpleJSPBean w create= n true" 
scope= " session ° >< /HEAN> 

<BESN narte= n sirtpleRequestMsg M type=-SirapXeJSPBean- creates "true" 

scope= " request " >< /HEAN> 

<% 

SinpleJSPBean sinpleApplicatianMsg =» 

( SinpleJSPBean) 
getServletContext ( ) .getAtt^iJbrute ("siirpleAr^licationMsg'') ; 
%> 



<htral> 

<head><title>Siinple JSP</titlex/head> 
<body> 
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<iitg src^banner.gif ■ alt-'faanoer image- heighten W idth=584xp> 

<hl>Sirople JSP page</hl> 

<% if (sinple^plicatianMsg J= null) { %> 

<B>Application Bean:</B> <%=siitple^licatianMsg.getMessage() %><br> 
<% } %> 

<B>Sessian Bean:</B> <%= sinpleSessicmMsg.getMessage() %> <BR> 
<B>Request Bean:</B> <%* sinpleRequestMsg.getMessageO %> <BR> 

</body> 
</html> 



Figure 8. simple. JSP code OS1 

When this file is processed by the JSP processor, the _simple.xjsp.java file i< 
generated. In Figure 9 on page 19, only a snippet of code is shown. Please 
refer to Appendix B, "Sample Code" on page 549, for all of the code and an 
example of the code generated by the JSP 1.0 compiler. 

package pageconpile; 

import java.io.*; 
import java.util.*; 
import javax.servlet.*; 
import javax.servlet.http.*; 
iraport java. beans. Beans; 

import con . ibrn . servle t . j sp . ht tp . pageconpile . ParamsHt tpServletRequest ; 
import com . ibra . servle t . j sp . ht tp . pagecorapile . ServletUt il ,- 
iraport com. ibra. servlet . j sp . ht tp . pagecompile . f ilecache . CharPileDa ta ; 
iraport cxra- ito. servle t.jsp.http.pag^ 

import SimpleJSPBean; 

public class _simple_xjsp extends javax.servlet .http.HttpServlet { 
private static final String sources [] a new String [J { 
"c : \\websphere\\appserver\\h^ 
web\\siraple . j sp * , 

}; 

private static final long lastModif ied [] = { 
926708647000L, 

}; 

public void service (HttpServletReguest request, 
HttpServletRespanse response) 
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throws IOException, ServletException 



} 

SirapleJSEBean sinpleSessicnMsg= (SimpleJSPBean) 
request . getAttribute ( " simpleSessianMsg" ) ; 
if ( simpleSessianMsg null ) 

throw new ServletExcept ion ( "Invalid BEAN name: 
simpleSessianMsg 1 ' ) ; 

f 

java.util. Properties p ~ new java.util.PropertiesO ; 
java.util.&iumeration e = request. getPaj^neterNamesO ; 
while (e.hasMoreElementsO) { 

String name « (String) e.nextElenent () ; 

p . put (name , request . getParameter (name) ) ; 

com. ibrn. servlet . util . BeansUtil . setProperties (simpleSessianMsg, p) ■ 



} 

Figure 9. Code snippet of the _simple_xjsp.java file generated by the JSP processor 

1.4.2 JSPIifecycle 

Since after compilation, JSPs generate a servlet, their life cycle is similar to 
that of a servlet. When the ServletEngine receives a request for a JSP file it 
checks to see if the servlet already exists or if the JSP file has changed since 
the last time it was invoked. If the servlet for the JSP does not exist in the 
application classpath or if the JSP file was changed since the last time it was 
loaded, the servlet engine passes the request to the JSP processor (or the 
pagecompile servlet). This creates another Java and .class file for the 
requested JSP file. These files are placed in the application classpath. The 
servletengine then creates an instance of the class file and calls the servlet 
serviceQ method in response to the request. Once the .class and Java files 
have been created by the JSP processor, all the subsequent requests for the 
JSP servlet are handled by the instance of the servlet that was created by the 
servletengine. By default, the JSP syntax in a JSP file is converted to Java 
code by the processor and this code is placed in the service() method of the 
generated class file. This default behavior can be overridden by using the 
method directive in the JSP file. 

The JSP servlet is terminated when the servletengine no longer needs the 
servlet or a new instance of the servlet is being loaded by the servletengine. 
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In doing so, the destroyO method in the servlet is called. If there is a need to 

reS ° u , rces or if ,he P revious ^uest to the servlet times out, Then 
also, the servleteng.ne can call the destroyO method of the servlet. 

1.4.3 JSP access models 

When using JSPs there are commonly two types of access models used: 

1 . JSP file handles both the request and the response 

In this model the JSP file handles both the request and the response to 
and from the client browser. The JSP passes the request to beans or other 
components to generate the dynamic content. The response is sent back 
to the JSP file from the beans, which in turn sends it back to the client 
browser. 

2. JSP handles response, servlet handles request 

In this model, the client request is sent to the servlet, which handles the 
dynamic content generation. It then calls a JSP file to send the response 
back to the client Using this model, one can effectively separate the 
business logic from the content display. 

These two JSP access models are discussed in more detail in the redbook 
Patterns for e-business:User to Business Patterns for Topology 1 and 2 usino 
WebSphere Advanced Edition, SG24-5864-00. 

1.4.4 JSP syntax 

In WebSphere V3, JSP conforms to the JavaServer Pages Specifications 
0.91 or 1.0 from Sun Microsystems. IBM has added some enhancements 
particularly in the area of database access. The Sun JSP 1.0 specification 
can be found at: 

http://java.mm.com/products/jsp/dcjwnlc)ad.htral 

A full discussion of JSP syntax including the differences between Version 
0.91 and 1.0, and details of the IBM extensions can be found in the redbook 
WebSphere Studio and Visual Age for Java Servlet and JSP Proarammina 
SG24-5755-00 



1.5 Enterprise Java Server (EJS) Runtime 

The Enterprise Java Server (EJS) Runtime provides support for the 
Enterprise Java beans (EJB) programming model in which enterprise beans 
are managed by containers. Containers, in turn are executed within servers 
which are operating system processes that contain their own Java Virtual 
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Machine (JVM). Each JVM is managed by the System Management 
infrastructure of the application server. 



The SM infrastructure allows the execution environment to be defined, 
enabled and monitored. The execution environment is made up of beans 
containers and servers. 

For more detailed descriptions and examples on each of the EJS functions 
please refer to 2.1, "IBM WebSphere Application Server components* on 
page 31. 

1.5.1 Enhancements to the IBM extensions required for the EJS 

The EJS programing model utilizes the RMI/IIOP model to provide distribution 
for the EJBs in standard and advanced releases of the EJS. The enterprise 
release of EJS requires the use of Interface Definition Language (IDL) to 
allow interoperability with the Component Broker (CB). 

Some of the existing IBM extensions in the IBM Java ORB have been 
re-implemented as an effort by the Component Broker team to enhance the 
JBroker Java ORB to support the EJS. Some of these features are briefly 
discussed below. 

1.5.1.1 Persistent Name Service (PNS) 

PNS is not an ORB feature but it is required to provide reference to the 
persistent objects. PNS implements CORBA CosNaming specification and 
this mechanism will be standardized for pluggable persistence. 

1.5.1.2 Object Resolver 

The Object Resolver provides a pluggable interface to allow an external class 
to act as a specialized object adapter. 

1.5.1.3 Request interceptor (Rl) 

The Rl allows access to the request header after marshalling out and before 
demarshalling in. This was done because the Request and Message 
Interceptor design from the original Sun ORB was not compatible with how 
C++ ORB handled interceptors. 

1.5.1.4 Property setting and getting flags 

Since the OMG defines only a couple of basic properties 

(org.orag.OORBA.CRBClass, org . omg . OQRBA . CRBSingletanClass) , they are not 

enough for IBM-specific properties. Support for these properties has been 
added and it will affect the method ORB.set_parameters and other affiliated 
methods. 
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1.5.1.5 JNDI support 

EJS implements the Java JNDI APIs to support the CORBA CosNaming. 

1.5.1.6 Java Transaction Service (JTS) 

JTS supports the ORB. This is done by implementing the Request 
Interceptors, which allows the JTS to be enabled by the ORB. 

1.5.1.7 Browser callbacks 

Normally, a client makes method calls to an object residing on the server. 
This is done when the server creates a listener socket and the client opens a 
port to that socket. By using the same listener socket, created by the server, 
and the port, opened by the client, functionality has been added for the server 
to make method calls to the object residing in the client. The roles have been 
essentially reversed. This is possible only in the case of signed applets. A 
similar capability has been added to the C++ ORB. 

1.5.2 New features in Java ORB required for the EJS 

Some of the new features in the IBM Java ORB, that are required by the EJS 
runtime have been briefly discussed below. 

1 .5.2.1 PI uggable feature framework 

In WebSphere V3.0, special emphasis has been paid to providing a very 
pluggable component-based framework. This kind of framework will take care 
of problems arising from receiving frequent updates of the Java ORB from 
Sun Microsystems and it will meet the needs of different internal customers 
with varying requirements. This feature is meant for private use only by the 
ORB team 

1.5.2.2 Pluggable transport layer 

In order to support any environment, it is necessary to have a pluggable 
transport layer. EJS has a pluggable transport layer, which means that the 
socket creation will have to take place in this layer. Other ramifications are 
that the CDRInputStream and CDROutputStream will also have to be 
replaceable. 

1.5.2.3 SSL support 

Support for the SSL interface on the server side has been provided. Using the 
MIME encoded HOP allows browsers and Web servers to use SSL. By 
selecting to enable SSL, the user can force an SSL connection between the 
client and Web server for greater protection of the user ID and password data. 
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1.5.2.4 Mime-encoded HOP tunneling with HTTP 

HOP tunneling means sending HOP messages embedded in an HTTP 
request/response. When the client or a firewall does not allow a post method 
the m.me encoded HOP tunneling technique can be used. This techntaue 
allows the m.me encoded HOP to tunnel through an HTTP firewall or Web 
server as an HTTP message. 




Figure 10. Mime encoded HOP tunneling through a 3-tier framework 

1.5.2.5 HOP tunneling 

There are 2 types of HOP tunneling. In the first approach, multiple HOP 
messages are embedded in an HTTP request and are communicated to the 
ORB using sockets. This approach has some security implications on Web 
servers and will not be used. The second approach is to attach the HOP 
request to a single HTTP request as a parameter with binary data. This 
request reaches the ORB using the servlet that is started by the HTTP 
request. The response is then sent back as binary HOP data. This approach 
is used since it is more secure. 
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1.5.2.6 HOP firewall support 

SOCKS V5 is used to provide the HOP firewall support by providina 
authenticated connections. 

1.5.2.7 HOP red! rector 

HOP redirector works in a similar fashion to the proxy firewall. It copies any 
replies/requests on a socket to a socket on which the ORB is connected. 

1.5.2.8 Configurable requests time-outs 

Only client-side timeouts have been implemented. This is done by throwing 
the NO_RESPONSE system exception on the client side with the completion 
status of maybe. The timeouts are set by using two ORB properties: 

1. com.ibm.CORBA.RequestTimeout 

2. com.ibm.CORBA.LocateRequestTimeout 

The default value for both of these timeouts is 0. A timeout value of 0 means 
an infinite timeout interval. 

1.5.2.9 eNetwork Dispatcher 

The eNetwork Dispatcher is a WebSphere HTTP sprayer used from Work 
Load Management (WLM). 

1.5.2.10 LDAP naming service 

EJS provides the LDAP naming service support indirectly through a JDBC 
layer implemented for CosNaming. As part of LDAP support, the EJS also 
supports the URL context. 

1.5.2.11 Work Load Management support (WLM) 

WLM distributes the workload or requests across a server group. This 
functionality is supported in WebSphere V3. Smart proxies are used within 
the client along with a WLM runtime. 



1.6 Preparing for Installation - What to change and why 

Before running the setup of WebSphere for version 3.0 it was necessary to 
make some of the following changes, to ensure a good install. These hints 
were documented in the WebSphere Readme file that shipped with the 
product 
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1.6.1 Set the JAVA.HOME environment variable 

Setting this variable allowed the OLT install to find the correct files as 
discussed in 4.3.0.2, -Installing and configuring the OLT/OLD environment" 
on page 268. The 3.02 WebSphere install on NT completes successfully eve 
if the java_home variable is not set. 

For the Windows NT platform: 

1 . Open the Control Panel. 

2. Double click the System icon. 

3. Select the Environment tab. 




Figure 1 1. The Windows NT System Properties Environment settings 

4. Type in JAVA JHOME in the variable field. 

5. Type in your JDK path, for example c:\jdki.i. 7b in the value field. 

6. Click Set. 

7. Click OK. 
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For the AIX Platform: 

1. Log in as root or a super user. 

2. cd/etc 

3. Edit the environment file with an editor of choice, for example, vi. 

4. Add the line JAVAJO^/usr/j<fc_bas& 

5. Save the file and exit. Next time you log in the environment will be 
updated. Below is an example of our settings within the /etc/environment 
file: 



iS 3 ^i^ in: /etc : /^^/sbiii: /usr/ucb : /usr/bin/Xll : /sbin 
LfiNGeenDS 

IOCPATH=/usr/lib/nls/loc 

^^^ r/1W ^ 8/ ^ /%L/%N:/ ^ r / 1 ^/^ 6 / rt ^/*L/%N.cat 

! J™ M^?™ e j cn ™* *° tetexxnixie which objects to operate on 
2 SS-S^S* u 6 /etc/c ^ r ^ )os " ^ where the device dbjects 
#reside, winch are required for hardware configuration 
COMDnu/etc/objrepos 

# IMNSearch EBCS environnent variables 
IMQODNPIGSRV=/etc/MJSearch 
IMQCXMFIGCL=/etc/IMNSearcVal)Cshelo 

# Added by Steen 
JAVA_HCMB=/usr / j dk_base 



Figure 12. /etc/environment settings 

1.6.2 Increase the DB2 application heap size for the WAS database 

In order for the Admin Server to work correctly the application heap size must 
be changed from its default setting of 128 to a new value of 256. In the 3.02 
install on NT the installation will update this setting automatically for you. This 
can be done manually either through the DB2 UDB Control Center or through 
the db2 command line interface, below are examples of both. 

From the DB2 UDB Control Center: 

1. Open the Control Center and expand the system that the WAS Database 
resides on, so you can see the WAS DB on your screen, as shown below 
in Figure 13 on page 27- 
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Figure 13. DB2 UDB Control Center - the WAS database 



2. Right-click the WAS database icon and select Configure. 
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Figure 14. Configure the WAS database 

3. Select the Performance tab. 

4. Scroll down the list of parameters and select Application heap size. 

5. Change the value from 128 to 256. 
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Figure 15. How to change the application heap size 

6. Click OK. 

7. Close the Control Center. 
From the command line: 

1. Start up a DB2 Command Line window (NT) or ensure your 
~/sqllib/db2profile has been activated (AIX). 

2. Connect to the WAS database with a valid user ID and password: 
connect to was 

3. To update, type the following command: 

update db cfg for was using APPLHEAPSZ 256 

4. Disconnect all applications: 

force applications all 
terminate 

5. Then stop and start db2. 
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Chapter 2. WebSphere Application Server overview 

This chapter will give a high-level overview of the Enterprise Java Server 
functions as deployed in IBM WebSphere V 3.0. 



2.1 IBM WebSphere Application Server components 

WebSphere Enterprise edition ships with two different Enterprise Java 
Servers as discussed in 1.3.2, "EJB architecture in brier on page 12 The 
following is an overview of the main components in the EJS provided by 
WebSphere Advanced Edition (AE) and a brief look at the main components 
o he EJS provided by Component Broker (CB). We also discuss the features 
of WebSphere Standard Edition because they are included in Advanced 
Edition and they provide the necessary foundation for Advanced Edition 
functions. 

2.1.1 Architecture overview 

This section gives an overview of the components in the general EJS 
architecture. 

Enterprise Java Services (EJS) refers to the infrastructure designed to run 
servlets and Enterprise Java beans. 

The EJS is based on Sun's Enterprise JavaBeans Technology specifications 
that specify an enterprise Java platform defined through a set of standard 
Java APIs that provide access to existing infrastructure services. 

2.1.1.1 EJS architecture 

An EJB server provides the following components: 

• The EJB server runtime 

The server runtime can be seen as a generic server (or model/template 
server) from which the Web application server instances can be modeled. 
EJBs live in containers that again live in the server runtime (Web 
application server) see Figure 18 on page 37. 

Servlets also live in a special container (servlet engine) that again live in 
the server runtime (Web application server) see Figure 17 on page 36. 

• The EJB containers 

EJB containers are provided following the requirements as described in 
the Enterprise JavaBeans specifications Version 1 .0 (for further 
information see http://java.sim. coVproducts/ejb/). Furthermore, IBM 
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provides additional features for example, entity bean support with bean 
managed or container managed persistency and a simple deployment 
tool. 

See 2.1.2, "Enterprise Java beans and containers" on page 39 for more 
details on containers and EJBs. 

• The Enterprise Java beans 

This combination of components provides a number of services. These are: 

• A deployment tool 

When an EJB has been developed it has to be transformed into a form that 
enables it to be managed and accessed. The transformation is referred to 
as EJB deployment. 

To deploy an EJB you will normally use a built-in tool of an IDE (Integrated 
Development Environment) or a stand alone tool. 

See 2.1.4, "Deployment tools 0 on page 40 for more details. 

• Naming services 

The IBM WebSphere Application server architecture provides naming and 
directory services to provide an interface to find EJBs based on the name 
or an attached attribute. 

In IBM WebSphere the Java Naming and Directory Interface (JNDI) is 
used to provide a common interface to the actual naming and directory 
service that is being used. 

JNDI provides an Application Program Interface (API) to be accessed 
through a Java application and a Service Provider Interface (SPI) to 
specify the interface to existing and widely used name and/or directory 
services. The purpose of providing an open SPI specification is to make 
the JNDI independent of the specific naming or directory service 
implementation used. 

For further information on the JNDI specifications see: 

http : // j ava . sun . coca/products/ jndi/ 

For more details on naming and directory services see Chapter 7, 
"WebSphere access control and security" on page,363. 

• Security services 

The security services provide support for Web resources (for example, 
HTML, JSP and CGI files), servlets and EJBs. 

The security authorization information, authentication and delegation 
policies will typically be defined using the IBM WebSphere Administrative 
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Console. In WebSphere Advanced the security service is an EJB server 
that contains security beans. 

See Chapter 7, "WebSphere access control and security" on page 363 for 
more details on security. 

• Work Load Management 

A Work load management (WLM) mechanism is provided to make scaling 
of enterprise applications running on IBM WebSphere Application server 
possible. 

Workload Management is a service that improves the scalability of an EJB 
server runtime environment by grouping multiple servers together into a 
server group. EJB clients can access this server group as if it was a single 
server. The actual server that responds to the client request will be 
transparently determined by the Workload Management service. 
WebSphere implements a number of different policies for how the 
Workload Management service will choose the server. 

We do not cover Workload Management in this book. 

• A persistence service 

This service provides support for the proper interaction between a bean 
and its data source to ensure that any persistent data is maintained. 

In AE this is accomplished by using the JDBC API to interface with 
relational databases and Java transaction support. 

In CB the persistent service is accomplished using the X/Open XA 
interface to relational databases and the OMG Object Transaction service. 

• A transaction service 

This service implements the transactional attributes specified in an EJB's 
deployment descriptor. 

• System management infrastructure 

The system management infrastructure enables management of Web 
server, Web application server and Web application resources. A client 
interface is provided for the administrator to manage these resources. 

An overview of the AE system management infrastructure is given in 2.1 .5, 
"System Management Infrastructure" on page 40. 

The IBM WebSphere Administrative Console is provided with IBM 
WebSphere 3.0 Advanced. 

See 2.1.5.1, "Systems management console" on page 41. 



Chapter 2. WebSphere Appfication Server overview 



33 



The client interface for the EJB server (CB) environment is the systems 
management end user interface. We do not discuss this interface in this 
redbook. Please refer to the redbook WebSphere Application Server 
Enterprise Edition Component Broker 3.0 First Steps, SG242033 for more 
details. 



2.1.1.2 WebSphere Application Server Standard Edition 

The WebSphere Application Server Standard Edition provides a basic Web 
application server environment for Web applications that typically consist of 
HTML files, JSP files, applets, servlets, image files and databases. 

The primary purpose of the IBM WebSphere Application Servers is to provide 
an environment into which scalable, portable, well performing and reliable 
Web applications can be developed and executed based on Java-based 
programming, standard techniques, Internet standards, standard middleware 
and database management systems. 

IBM WebSphere Application Server Standard Edition provides an 
environment where you can extend and enhance your Web applications by 
migrating your HTML to JSP. Since JSPs essentially are HTML files with 
additional JSP-specific tags you can use your HTML skills and standard 
development tools. 

IBM WebSphere Application Server compiles the JSPs (at runtime) and 
transfers them into servlets. However, this process is managed by IBM 
WebSphere Application Server and is transparent to the developer. 

Since JSPs can include Java code and you write your servlets in Java you 
can use Java in your development - if you want to or the requirements force 
you to. However, you are not necessarily required to do so. 

"Traditional" Web development components like CGI programs, Web Server 
APIs and client side scripting languages may also be utilized since an IBM 
Web Application Server setup includes a "traditional" Web server. 

IBM WebSphere Application Server Version 3 integrates with many different 
Web Servers and includes plug-ins for IBM HTTP Server, Apache, Lotus 
Domino Go V4.6.2.5, Lotus Domino, Netscape Enterprise Server, and 
Microsoft IIS. 

To integrate with a Web server you must select one or more of the plug-in 
extensions as shown in Figure 16 on page 35. 
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Figure 16. Web servers that integrate with the application server 

The application server provides the runtime environment for execution of 
servlets. See Figure 17 on page 36 for a view of this runtime architecture. 



The Web application server also provides a connection manager function that 
manages database connections. The connection manager provides an easy 
to use mechanism for reducing the resources required by Web applications 
when accessing databases. 

Furthermore, the Web application server provides transaction support 
through an implementation of Java Transaction Server (JTS) in relation with 
JDBC/XA databases. 

Finally, the IBM WebSphere Application Server Standard Edition architecture 
includes a system management infrastructure with two primary components 
the Administrative server and the Administrative client (console) (seeFigure 
17 on page 36). 

For further information on the system management structure see 2.1.5, 
"System Management Infrastructure" on page 40. 
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Figure 1 7. WebSphere Application Server Standard Edition 3.0 runtime architecture 



2.1.1.3 WebSphere Application Server Advanced Edition 

The WebSphere Application Server Advanced Edition (AE) has the functions 
found in the WebSphere Application Server Standard Edition plus support for 
EJBs and distributed (clustered) systems. This application server is one of 
two EJ8 servers provided in IBM WebSphere Enterprise Edition. 

Since IBM WebSphere Application Server Advanced Edition is an extension 
of the Standard Edition you can easily move an application developed for a 
server running Standard Edition to servers running Advanced Edition. 

The Web application server in IBM WebSphere Application Server Advanced 
Edition (see Figure 18 on page 37) includes support for EJB containers (for 
the EJBs) besides the servlet engine (for the servlets and JSPs) also found in 
Standard Edition. 
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Figure 18. WebSphere Application Server Advanced Edition 3.0 runtime architecture 

There is a single instance of the administrative server on a single node 
(physical machine). 

In a multi-node setup (cell) there will be a single instance of the administrative 
server on each node. The administrative servers contains identical 
configuration information and access the same configuration repository in the 
same database (see Figure 19 on page 38). 

The rationale is that you should be able to access any one of the 
administrative servers in a cell and see changes reflected on any other 
administrative server in the cell (single administrative image). 

The WebSphere administrative database can be located either on a separate 
database server (physical machine) or on one of the machines that host the 
administrative servers. However, each machine must have database server, 
client or connection software installed and configured to enable access to the 
common database. 
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If you plan to run the same Web applications and enterprise applications on 
more than one physical machine you will also have to ensure that all systems 
have access to identical (or the same) files and in identical locations in the 
directory structures. This can be accomplished either by creating identical 
files and directory structures on each machine or by using a shared file 
system. If the first method is used we would recommend that you establish an 
automatic or semi-automatic procedure to ensure that the data are identical. 



Node 2 




Figure 19. WebSphere Application Server Advanced Edition multi-node setup 

A concept of server groups has been implemented in the IBM WebSphere 
Application Server for management and control purposes. 

The following applies to the server group concept: 

• Server groups consist of one or more Web application servers. 

• A single Web application server can only belong to one server group. 

• A server group can be seen as a logical server. 

• Web application servers within a group are clones of each other. Clones in 
this context means logically identical application servers with respect to 
configuration of resources for example, containers and EJBs. 
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• The Web application servers within a server group may be distributed to 
different nodes (physical machines). 

The server group is very useful in relation to workload management A 
request can be forwarded to a server group and the request is handled by a 
server in the group while the specific server identity is hidden from the 
requester. 

2.1.2 Enterprise Java beans and containers 

The IBM WebSphere Application Server Version 3.0 server architecture 
provides a generic server (the Web application server, see Figure 18 on pace 
37) in which EJB containers live. 

One of the primary responsibilities of an EJB container is to provide a number 
of fundamental services for example, transaction, state, security and 
persistence to the EJB. The advantage being that it reduces the work 
required by the EJB developers and supports development of portable EJBs. 

Another responsibility of an EJB container is to create the interfaces (EJB 
Home and EJB Object) required for an EJB client to access a deployed EJB 
so the EJB client interacts indirectly with the EJB through the EJB container 




Figure 20. Client - EJB container relationship 



2.1.3 Servlets and the application server 

A special container (a servlet engine) is provided in IBM WebSphere 
Application Server to enable servlets to be run within the application server. 
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The servlet engine has been designed to be integrated as seamlessly as 
possible in the EJS architecture as well as in the security and system 
management infrastructure. The design approach allows for consistent 
system management for servlets and EJBs as appropriate while maintaining 
the typical servlet environment and characteristics intact. 

Servlets are created and managed as members of a Web application in IBM 
WebSphere Application Server Version 3.0. IBM WebSphere Application 
Server provides work load management support for servlets (as it does for 
EJBs) to allow requests for servlets within a server group to be distributed to 
application servers belonging to the group. 

2.1.4 Deployment tools 

When you have developed your Enterprise Java beans for example, using 
VisualAge for Java or manually, they have to be deployed. 

When you deploy an EJB you create or modify a Jar file which includes a 
description of the Jar file contents (the manifest), deployment descriptors, 
bean class files and potentially environment properties. 

To create a deployed EJB Jar file you can for example, use VisualAge for 
Java, the Jetace tool or you can use the tools available in the Java 
Development Kit (JDK). The Jetace tool is provided as part of the IBM 
WebSphere Application Server. 

After the EJB Jar file has been deployed for your IBM WebSphere Application 
Server it must be installed in your environment in accordance with the 
WebSphere administrative infrastructure. IBM WebSphere Application Server 
Advanced Edition provides the WebSphere Advanced Administrative Console 
to be used for EJB creation (installation). 

Depending on the requirements for your EJB you may even choose to deploy 
an undeployed Jar file during EJB creation using the WebSphere Advanced 
Administrative Console. 

You will also find a command line tool wlmjar with WebSphere Application 
Server Advanced Edition that can be used to create a workload-managed 
prepared version of your Jar file. 

2.1.5 System Management Infrastructure 

This section describes the IBM WebSphere Application Server administration 
model. 
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2.1.5.1 Systems management console 

The WebSphere Administrative Console is the system management console 
for IBM WebSphere Application Server Version 3.0 Advanced Edition. 

An administrative domain (sometimes referred to as a cell or sphere,) is a 
collection of managed nodes, that is, host machines. Each managed node 
has an administration server executing on that node that is responsible for 
configuring, monitoring, and managing the WebSphere servers that run on 
that node. A client graphical user interface is provided to enable the 
administrative domain to be defined. 




This Graphical User Interface (GUI) makes it easy to interact with the beans 
that were loaded by the adminserver. The front-end has a tab look and feel 
and has three main tabs as shown in Figure 22 on page 42, Figure 23 on 
page 43, and Figure 24 on page 45. The WebSphere Administrative Console 
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has three tab panes namely Types, Topology, and Tasks. These three panes 
are discussed below. 

2.1.6 The Types view 

The Types view is a hierarchical view of all resources on all nodes in the 
administrative domain. Each folder icon represents a different resource type. 
By selecting any object and right clicking, a context-sensitive menu appears. 
This menu has the basic tasks such as Create, Move, Default Properties. 

The Types pane is shown in Figure 22 on page 42. 




3/28/00 4:48 FB : Loading ... 
3/28/00 4:48 FB : Console Ready. 




Figure 22. WebSphere Advanced Administrative Console - Types tab 



2.1.7 The Topology view 

The Topology pane consists of the WebSphere Administrative Domain and all 
the managed nodes as shown in Figure 23 on page 43. For each managed 
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node there is an associated hierarchy of all the resources within that node. 
The resource attributes can be changed and methods can be invoked on 
these resources in this view also, just as in the Types view. 




Figure 23. WebSphere Advanced Administrative Console - Topology tab 
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2.1.8 The Tasks view 

The Tasks view shows different tasks that can be performed and is shown in 
Figure 24 on page 45. It consists of three task groups, which are briefly 
discussed below. 

2.1.8.1 Configuration tasks 

This group of tasks allows you to configure application servers, virtual hosts, 
servlet engines, web Applications, and enterprise applications. 

2.1.8.2 Performance tasks 

This task allows the user to launch the Resource Analyzer tool to monitor 
performance and load statistics. The Resource Analzer is dicussed in more 
detail in the redbook WebSphere V3 Performance Tuning Guide 
SG24-5657-00. 

2.1.8.3 Security tasks 

Using this task, you can apply security to enterprise applications and to the 
HTTP and EJB methods of resources such as servlets and enterprise beans. 
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./^WebSphere Acfvonccd Administrative Console 




Figure 24. WebSphere Advanced Administrative Console - Tasks tab 



Chapter 2. WebSphere Application Server overview 45 



8.1.6 Starting the LDAP directory server from the command line 

To start LDAP from the command line you should use the following command: 

/usr/ldap/bin/slapd 

8.1.7 Administration interface - Web 

From the Directory Server Web Admin you can perform several administrative 
task such as: 

• Configure a database 

• Configure a replica 

• Start up and shut down the server 

• Define an ACL 

• Add and delete suffixes 

• Add entries to the directory 

To use the Directory Web Admin you have to start up a Web browser and type 
in the Location field http://hostanme/idap 




Figure 405. fdap Web admin 
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For the user ID specify cn=root or the user that you specified in the 
administrator DN and password section in Figure 401 on page 413. 

For the password type the password that you specified in the administrator 
DN and password section and click the Logon button. 

8.1.8 DMT interface 

Use the DMT tool to: 

• Connect to one or more directory servers via SSL or non-SSL 
connections. 

• Display server properties and rebind to the server. 

• List, add, edit, and delete schema attributes and object classes. 

• List, add, edit, and delete directory entries. 

• Modify directory entry ACLs. 

• Search the directory tree. 

You can configure the tool to automatically connect to one or more servers 
and to log in particular Distinguished Names (DNs) when it is started. To 
configure the tool, edit the /usr/ldap/etc/dmt.conf DMT configuration file. For 
example, the property file contains these lines: 

• server1.url=ldap://localhost:389 

• serveM .security.bindDN= 

• serveM .security.password= 

• server! .security.ssl.keyclass= 

8.1.8.1 Log on to a server 

If a directory user DN and password are not provided in the DMT 
configuration file, the tool connects as an anonymous user when it is started. 
Although an anonymous user can browse the directory tree and schema, to 
perform directory updates, in most instances, you need to log on as a 
directory user. To modify the directory server schema you must log on as the 
server administrator. To log on as a different user: 

1. Click Server -> Rebind. 

2. Provide the user DN and password. 

3. Press Enter. 

To start the DMT too! enter dmt &. 
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Figure 40$. DMT 



For more information about how to use this tool, see: 

http: //www-4 . ibm. com/sof tware/netvork/directory/ 



8.1.9 Configuration files - attributes and objects classes 

The file /etc/slapd.conf contains configuration properties such as the SSL 
port, DB2 user, admin DN, and the admin password. 



M4Vj ZxEhb/ j FCEVab7B£2)CTV^ 58RneygaJdkz8iX2R< 
adhuriW 0 afc*raot" 

# IBM SecureWay Directory Server Configuration Pile V3.1.1 for ADC 

# CMJITCU: EDIT THIS FH£ WITH CARE 

# He in w i-ri naking all f^gnngpa through the server administration interface. 
sysLogLevelra 
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otixitHfX}/ tnp/ slapd . errors 
includeScheraa /etc/laapschena/V3 . system, at 
includeSchema /etc/ldapschema/V3 .ibm.at 
includeSchena /etc/ 1 riapschema/V3 .user . at 
includeScheraa /etc/ldapschema/V3 . system, oc 
includeSchena /etc/ldapschema/V3 . ibnL oc 
includeScheraa /etc/ldapGcheraa/V3 .user . oc 
ijocludeScheraa /etc/ldapschema/V3 .Idapsyntaxes 
includeScheraa /etc/16apschema/V3 .natrhingruleB 

# The next file is for schema changes. It's empty when the package is installed 
incLudeSchema /etc/ ldapschema/V3 .modifiedschfima 
scheroacheck V3_lenient 
port3S9 
securePort£36 
securityione 

#sslftuth options: serverai ifh/servexcl i pntauth 
sslAuth serverauth 
sslOertificate none 
sslCipherSpecs 12288 
sslKeyftingFile key.kdb 
sslKeyRi ngPileTWYmp 
TtEKxthzeads250 

uaitingthreads 75 
t-p>rmirc :>t "* >Trn * a Pmn* ar,t jrma. on 
timelindtdOO 
sizelimitSOO 

#pwencrypticn options: inask/none/crypt/SHA 
pwencxyption iraask 

fifjfrH fjnfiFifrnri» »Mwnwiffifi»firmfi»fni»» »rfriHnfifiHfffin» fififftffMfHHFifJff»rifrfjnfi»Hn#fff» Hwrronw 

# Idcf dRtahftse definitions 

»WHfifiriHfifififf» h h Hfifirif#»fffiHfifiHfnf»fififiif MfififjrifiiMrrMifffifiiifuifnr n Mninin w» fifffmif» »f#» ri Hfi 

database Idcf 
suffix *m=scbana« 

ff jt n it n ff rr rr if n n » m n n ri ff n n » n rr irn n fr » » f r r r f r f r rr rr rr n f i n if ir rr rr rr r> rr rr rr rr rr rr r M " "'»»"»»»„» nr.,,™™ 

# rdhra database definitions 
datahfta-tta-Jum 

pli^n Hnt-ahagp /lib/libback-rdbra.a rdfarbackendjnit 

suf f ix"o*IM, 0=05" 
database!* 

dbusezpw 

>148N>CKL9SSFc2/cpSVKLTOTj20^^ 



dbuseridldapdbe 
dbOocnections 6 
suffix "cn^localhost" 
readOolyoff 

# point ffr-jg path at your changelog conf file and uncoraraent 

# (it must be full path) 

^include /etr/ldapschena/ slapd. cl.crxif 



If you want to add a new object, modify or delete classes or attributes you can 
use the DMT tool. This tool also lets you know how the standard object 
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classes are created. Any attribute or class modification dynamically changes 
the directory schema. 

To add an object click Schema -> Object Classes -> Add Object class. 

To add an attribute click Schema -> Attributes -> Add attribute. 
For further information see the SecureWay Directory Web site at: 

http: //www-4 . ihra. cora/sof tware/network/directory/ . 

8.1.10 LDAP commands 

We now show you how to use some of the more important LDAP commands 
from the user's point of view. There are more specific IBM SecureWay LDAP 
commands for administrative purposes. Other vendors who have 
implemented these commands may be using different flags. 

8.1.10.1 LDIF format 

LDAP Data Interchange Format (LDIF) is a format for representing LDAP 
entries in text form. It is widely used and accepted as a de-facto standard. 
LDIF is used by the Idapmodify, Idapadd, and Idapsearch command-line 
utilities. The basic form for an entry in an LDIF file is as follows: 

• dn: distinguished name> 

• objectClass: <object class> 

• objectClass: <object class> 

• <attrtype>: <attrvalue 

• <attrtype>: <attrvalue> 

An LDIF file consists of a series of records separated by a blank line. A record 
is a directory entry with a mandatory DN and at least an objectClass if the 
record is a new entry. If the record is for an update only, the DN is required. 
Some attributes, required by an objectClass, must be defined. Attribute 
values can be clear text, such as a name, or they can be Base64 encoded 
binary data, such as for a JPEG picture. 

8.1.10.2 The Idapmodify and Idapadd utilities 

The Idapmodify utility is a command-line utility built around the ldap_modify() 
API. The utility opens a connection to an LDAP server, binds to the server, 
and modifies an entry. The entry information is read from standard input or 
from a file. The Idapadd utility is implemented as a renamed version of 
Idapmodify. The Idapadd works the same way as the Idapmodify with the -a 
flag set. The syntax of the utility is: 
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ldapmoclify [options] [-f <ldif input file>] 
ldapadd [options] [-f <ldif input file>] 

Some options are: 

• -h host LDAP server host name 

• -p port LDAP server port number, default 389 

• -D dnbind dn by default anonymous 

• -w bind password 

• ~R specifies that referrals are not to be automatically followed 

• -M manage referral objects as normal entries 

• -V LDAP protocol version (2 or 3; default is 3) 

• -C charset character set name to use, as registered with 

IANA 

• -b Assumes that any values that start with a / are binary values, and that 

the actual value is in a file whose path is specified in the 
place where values normally appear 

• -c continuous operation; do not stop processing on error 

• -n show what would be done but don't actually do it 

• -v verbose mode 

• -d level set debug level in LDAP library 

Examples 

Following are some examples using the LDAP commands: 

ldapadd -h rs600030 -D "cn^root" -w swall7r -f add.ldif 

This is the add.ldif's contents: 



ateWarisa, ou^ITSO, o=itora,c=us 

objectclass=ePerBcn 
cfojectclass=persan 
cbjecAclass»ixietacgfPGXGca 
cbjectcla88stcp 

uid^Karisa 

ttail=*ferisa®ar.ibm.can 
cn^Marisa 

userPafisward=swall7r 
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Now let's modify the Marisa's mail attribute: 

ldapmodify -h rs600030 -D *cn=root" -w ewall7r -d mod.ldif 



cso^Marisa , ou^TISO , o=ibm, c=us 

obj ectclaes=ePerBan 

obj ectcl ass=perscn 

obj ectclass=inet]QpgPeirscp 

dbj ectdasG *=top 

obj ect^ lass organizational FfeTBCgi , 
RBil=cicsMazx3ar. Uan.com 



To validate the change we ran the Idapsearch command: 

ldapsearch -h rs600030 -b "ou«ITSO, o^IBM, c=US" cn=Marisa 



ens*brisa , ouaTISO, o=Ibra, e*us 

sa=cic£Man 

uid=Warisa 

GQ=MariBa 

cbjectclass=ePerBaa 
obj ectclasst=^cx'fckj>t!i 
cbjectcla6s=inett)rgFex5ari 
objectclass=top 

cbjec^laf^anrgrmizarinnaiagrson 
nail^ciceMazxaar . itan. can 



8.1.10.3 The ldapsearch utility 

The ldapsearch utility is a command-line utility built around the 
ldap_search() API. The utility opens a connection to an LDAP server, binds to 
the server, and performs a search using a specified search filter. If the 
request finds one or more entries, the requested attributes are retrieved, and 
the entries and values are printed to standard output. If no attributes are 
specified, all attributes associated with each returned entry are displayed. 
The syntax is: 

ldapsearch [options] filter [attributes] 

The significant parameter options for the Idapsearch tool are: 

• -h LDAP server host name 

• -p LDAP server port number 

• -D bind dn 

• -w bind password 

• -b base dn for search; LDAPJ3ASEDN in environment is default 

• -s search scope (base, one, or sub) 
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• -a how to reference aliases (never, always, search, or find) 

• -I time limit (in seconds) for search 

• -2 size limit (in entries) for search 

• -f perform sequence of searches using filters in file 

• -A retrieve attribute names only (no values) 

• -R do not automatically chase referrals 

• -M manage referral objects as normal entries 

• -V LDAP protocol version (2 or 3; default is 3) 

• -C character set name to use, as registered with IANA 

• -B do not suppress printing of non-ASCII values 

• -L print entries in LDIF format (-B is implied) 

• -F print separation between attribute names and values 

• -t write values to files in /tmp 

• -n show what would be done but don't actually do it 

• -v run in verbose mode 

• -d set debug level to level in LDAP library 

The search filter, in many cases, will either be a simple attribute search (such 
as cn=Smith) or for all attributes (cn=*). Search filters, however, can be fairly 
complex, and there is a separate RFC (RFC 2254) that you should refer to if 
you need all the details. The following is a brief description of search filters. A 
search filter defines criteria that an entry must match to be returned from a 
search. The basic component of a search filter is an attribute value assertion 
of the form: 

attribute operator value 

For example, to search for a person named John Smith, the search filter 
would be cn=John Smith. In this case, cn is the attribute, = is the operator, 
and John Smith is the value. This search filter matches entries with the 
common name John Smith. Table 9 on page 4241 ists the operators for search 
filters. 
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Table 9. Operators 



Operator 


Description 


Example 




Returns entries whose attribute is 
equal to the value. 


cn=John Smith finds the 
entry with the common 
name John Smith. 


>= 


Returns entries whose attribute is 
greater than or equal to the value. 


sn>=smith finds all entries 
from smith to z\ 


<= 


Returns entries whose attribute is 
less than or equal to the value. 


sn<=smith finds all entries 
from a* to smith. 




Returns entries that have a vaJue 
set tor that attribute. 


sn=* finds all entries that 
have the sn attribute. 




Returns entries whose attribute 
value approximately matches the 
specified value. Typically, this is 
an algorithm that matches words 
that sound alike. 


sn~= smit might find the 
entry "snssmith". 



The character matches any substring and can be used with the = operator. 
For example, cn=J*Smi* would match John Smith and Jan Smitty. Search 
filters can be combined with Boolean operators to form more complex search 
filters. The syntax for combining search filters is: 

( '&■ or T (filterl) (filter2) (filter3) ...) 

(•!" (filter)) 

The Boolean operators are listed in the following table: 



Table 10. Operators 



Boolean operator 


Description 


& 


Returns entries matching all specified filter 
criteria. 


I 


Returns entries matching one or more of 
the filter criteria. 


I 


Returns entries for which the filter is not 
true. This operator can only be applied to 
a single filter. ( i (filter) ) is valid, 
but ( i (f ilterl) (f ilter2) ) is 
not. 
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Examples: 

1. Retrieve all the entries with a person object defined; 

ldapsearch -h rs600030 -b "oIBM^^US" obj ectclass=person 

2. Retrieve all the entries with an e-mail ending in a ibm.com B ; 

ldapsearch -h rs600030 -b n o=IBM,c=US n mail=*ibm.cora 

3. Retrieve all the entries with cn=Marina and mail=*ibm.com; 

ldapsearch -h rs6 00030 -b "o=IBM,c=US n 
" (& (cn==Marisa) (mail«*ibm. com) ) " 

Note that we used " " in the filter. The reason was that on AIX the ksh 
preprocesses the () directive with B " and doesn't preprocess the 
contents. 

4. Retrieve all entries with mail=*ibm.com and cn not equal to Karina, root; 

ldapsearch -h rs600030 -b °o=IBM,c=U5 n 

" <&(mail=*ibm.com) (1 ( | (cn=Karina) (cn=root) ) ) ) " 

8.1.10.4 The Idapdelete utility 

The Idapdelete utility is built around the ldap_de!ete() API. The utility opens a 
connection to an LOAP server, binds to the server, and deletes one or more 
entries. The distinguished names (DNs) of the entries to delete are read from 
standard input or from a file. 

The syntax is: 

Idapdelete [options] [DNs] 
Idapdelete [options] [-f file] 

where: 

an: one or more items to delete 

file: name of input file containing items to delete 

If neither an or file is specified then items are read from standard input. The 
options are: 

-h LDAP server host name 
-p LDAP server port number 
-D bind dn 
-w bind password 

-Z use a secure Idap connection (SSL) 



Chapter 8. Directory Services 425 



-K file to use for keys 

-P keyfile password 

-N private key name to use in keyfile 

-m perform SASL bind with the given mechanism 

-R do not chase referrals 

-M Manage referral objects as normal entries 

-0 maximum number of referrals to follow in a sequence 

-V LDAP protocol version (2 or 3; default is 3) 

-C character set name to use, as registered with IANA 

-c continuous operation; do not stop processing on error 

-n show what would be done but don't actually do it 

-v verbose mode 

-d level (set debug level in LDAP library 
Examples: 

1 . Delete the entries with cn=Karina: 

ldapdelete -h rs6 00030 -D "cn^root" -w swall7r "cn«Karina, 
ou^ITSO, o=IBM, c=US" 

2. Delete two entries from a file called IdapDelete: 

( \ 

"CTi**farisa, ou=IT90, o=IEM, c=CB" 
"cn?Cristian,ouB^SO # o=^IBM r cs^B ,, 
s . J 

ldapdelete -h rs6 00030 -D swall7r -f IdapDelete 

8.1.11 Configuring the Netscape address book to use LDAP 

The Netscape address book is an LDAP-enabled application, which means 
that it can get information from an LDAP directory. Other products like 
Microsoft Internet Explorer are LDAP enabled too. 

In these examples we show you how to set up the Netscape address book to 
use IBM SecureWay Directory V3.1.1. 

1 . Start the Netscape address book. 
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Figure 407. Netscape Address book 
2. Create a new directory. 

Click File -> New Directory and you should see the dialog box shown in 
Figure 408. 




Figure 408. Directory Server Property dialog box 

The fields are: 
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• Description: Title description is optional 

• LDAP Server: Host name of the Directory Server 

• Search Root: Base DN 

• Port Number: By default 389 

• Don't show more than: Maximum number of entries returned 

• Secure: Use SSL 

• Login with name and password: Used to bind with user ID and password 
3. To see all entries, type * in the Show names containing field: 




Figure 409. Search 



8.1.12 WebSphere and LDAP 

WebSphere supports authentication mechanisms based on validating 
credentials such as user ID and password, certificates, or tokens. Credentials 
are verified against a user registry supporting such a schema. For example, 
user IDs and password-based authentication can be based on the LDAP user 
registry where authentication is performed using an LDAP bind. A certificate 
validation list may be used in cases where authentication of the user is based 
on the client certificate presented by the user over a mutual SSL connection. 
WebSphere supports a three-party authentication schema, one in which the 
client principal and server principal are authenticated to a mutually trusted 
third-party. The third-party in this case is the authentication token server. An 
advantage of a three-party schema is that administration of the user registry 
can be controlled centrally. 
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WebSphere supports the following list of LDAP Directory Servers: 

• Netscape Directory Server Version 3.x and 4.x 

• SecureWay Directory Server Version 2.1 and 3.1.1 

• Lotus Domino Version 4.6 and 5.0 

Additional attributes are available for customizing any of the default filters to 
fit a Directory Server not listed above. 

8.1.13 Configuring WebSphere to use LDAP 

Start the WebSphere Advanced Administrative Console. 

1. Select the Tasks tab, double-click the Security option and you will see a 
window similar to Figure 410: 




Figure 410. Security global settings 

2. Select Specify Global Settings and click the Enable Security field. 

Enable Security: Specifies whether to enable or turn off server security. 
If you deselect this field all the security options specified on resources 
will be unprotected. 
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Security Cache TimeOut: Specifies how many seconds the server 
should cache security information received from the user registry 
(Operating System registry or Directory Server "LDAP"). 

3. Select the Application Defaults tab to specify the following properties: 

Realm Name: Is the security domain where the user will be 
authenticated? If the principal tries to access a resource in a different 
realm, the principal will be prompted to log in to the new realm. It is 
used if Single Sign On (SSO) is used. 

Challenge Type: This option specifies the mechanism used by the 
principal to interchange credentials. If you select Basic, it means that 
the Web browser will prompt the principal for a user ID and password. 




Figure 411. Global settings - Applications Defaults 



4. Click the Authentication Mechanism tab. On this page you specify the 
mechanism used by the security server to authenticate the principal's 
credentials. See Figure 412 on page 431. 
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Lightweight Third Party Authentication (LTPA): Select this option to use 
the LDAP directory server as the registry system. 

Token Expiration: Specifies how many minutes can pass before a client 
using an LTPA token must be authenticated again. We used the default 
value. 



Basso 



4 ^ ^^f^\Y^<^^^ *Mjnmr*Urtfr?yZ®t*<&S 





10/22/99 4:56 « : AUDIT [rsSCOOaO/Dcfault Server] : Loading eervlet: "snoop" 
10/22/99 4:56 PH : AUDIT I r»6G 0030 Ate fault Server]: [Servlet L08J: "SrtoopServLet; inif 
10/22/99 4:56 » : ADD IT [r8600030 /Default Server] : Servlat available for service: "snoop* 



Figure 412. Global settings - Authentication Mechanism 



Click the User Registry tab. On this page we specify basic information to 
use the LDAP Directory Server as shown in Figure 413 on page 433. 
These are the attributes that you should change: 

Security Server ID: Type a valid user ID registered in the LDAP 
Directory server used by the Application Server V3 Security server. 
The user ID should have some administrative privileges. 

Security Server Password: Type the password for the security server ID 
user. 
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Directory Type: Select the directory to be used. In our case we used 
SecureWay. 

Host: Type the host name where the LDAP directory is running. In this 
example it is rs600030. 

Port: Specify the LDAP directory port, which by default is 389. We used 
the default value. 

Base Distinguished Name: Use this property to specify the starting 
point for LDAP searches. If you plan to use Domino directory you can 
leave this field blank. In this example we used ou=ITSO,o=IBM,c=US. 
Bind Distinguished Name: Use this property to specify the DN to be 
used for the application server. If you leave it blank the Application 
Server binds using the anonymous ID. In this field we used the LDAP 
administrator cn=root. 

Bind Password: Use this field to specify the password used to bind to 
the LDAP directory. We used the LDAP administrator's password. 

Note: If you get the exception 

org.omg.CORBA.TRANSACTION_ROLLEDBACK when you click the 
Finished button, it means that you probably specified an incorrect user 
ID or password. 
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Figure 413. User Registry properties 



6. Click the Finished button. 

Note: For any change made on the global security settings you must 
restart the node. To do so, click Topology -> WebSphere Admin Domain 
-> Host Name (rs600030). Then right-click the mouse button and select 
stop or restart. You must leave the administrative console. 

You can customize more LOAP attributes such as search filters and certificate 
mapping as shown in Figure 414: 
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Figure 414. Advanced properties 

7. The next step consists of applied security on an application. This means 
performing the following steps: 

a. Configure an enterprise application. 

b. Configure application security. 

c. Configure resource security. 

d. Assign permissions. 

For more information about how to perform these tasks see the 
WebSphere documentation available in the directory 
/usr/WebSphere/AppServer/web/doc/begin_here/index.html 

8.1.14 JNDI 

JNDI defined by Sun Microsystems provides naming and directory functions 
to Java programs. JNDI is an API independent of any specific directory 
service implementation. 

The definition prevents, by design, the appearance of any 
implementation-specific artifacts in the API. The API is designed to cover the 
common case. JNDI was developed as part of Java Enterprise API set which 
also includes Enterprise Java beans (EJB) and Java Database Connectivity 
(JDBC). The EJB specification has a special relationship with JNDI because 
EJB uses this mechanism to find Entity beans or Sessions beans. 
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